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ABSTRACT 


The intent of this report is to provide practical 
assistance to NASA project managers, especially the newly 
appointed project manager. It contains ready challenges 
and prompting in all areas of project work. Even though 
it is written from the point of view of a major project 
manager in NASA, this report can be used with small adjust- 
ment by any government manager of a major project. 

The research was performed under NASA Grant No. 43-001-116. 
It consisted of investigating methods and procedures involved 
in the management of major NASA projects. The approaches 
used to manage these projects were studied and existing 
documents on NASA management were reviewed. The principal 
investigator, Professor Lee B. James, The University of 
Tennessee Space Institute, Tullahoma, Tennessee, was able 
to apply first hand knowledge to this research. He previously 
had been a NASA manager in NASA Headquarters and at a NASA 
Center . 
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PREFACE 


The educational world has long lamented and discussed 
the shortage of research in the management field. Coupled 
with this is a natural lack of depth in many management areas. 
As pointed out by Dr. Sayles in Business Horizons, the 
’’Behavioral Approach" to management as a result of lavish 
inducements by the Ford Foundation, is the only concept with 
adequate field work and publications. Part of this problem 
is the fault of the researchers. Little has been added to 
the usefulness of various management approaches since manage- 
ment has become formalized by such writers as Taylor and Weber 
back in the early 1900 ’s. 

Besides the behavioral approach with hygienic needs, 
satisliers, theory X , managerial grid, etc., we now have 
numerous case studies. However, most of the case studies are 
remarkably related to behavior. We can also fall back on 
management studies under the traditional standard headings 
of organization, planning, measuring, controlling, and de- 
cision-making. In fact, most of the recent writers with exotic 
titles such as "A Systems Approach to Management" have these 
same headings for chapter titles. 1 * 2 * 

This leaves us with the mathematical or quantitative 
approaches. Although these studies have their place, anyone 
who observes complex organizations knows that little resem- 
blance exists between formal models of decision-making and 
the real system of interaction. There are, however, in 
addition to operations research and math models, related 

♦Superscript numerals are used for text references. 
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business area subjects such as finance, PERT, etc., which 
are quite useful to a manager. These of course are very 
specialized and do not help him enough with an overall approach 

Not enough research is available on the practical, 

"every day" management process and its relationship to the 
working organizations we are using. There has been too 
little concern with other than the behavioral aspects of 
leadership. Present writings on control and communication 
have too little meaning in a dynamic, changing project. 
Budgeting and management by objective teachings are based on 
firm plans and historical data. Busy project managers are 
often forced to develop their own new and updated approaches 
to needs as management information systems. No one deals 
sufficiently with changing objectives, unstable technology, 
one-of-a-kind outputs, relationships of numerous professional 
specialists and the effect of outside pressures. This may 
be too severely stated, but the hard working project manager 
really needs more than background in order to start out right. 
Yes, the project manager's job is among the more demanding 
social inventions of our time. There are a number of good 
training courses available to project managers, but they may 
not have the time to undertake such courses. 

NASA Headquarters, specifically the Policy and University 
Affairs Office, has recognized the need for some practical 
assistance to the project manager. They have issued an initial 
grant to the University of Tennessee to take a step. In 
making the grant, they expressed interest in treating a small 
number of management system decisions that must be made by 
the project manager and write a report that could be used as 
a reference for government project managers. 

It is hoped that this report will be a practical step 
toward aiding the harassed project manager, from whom so much 
is expected and so little given. One of the failings of this 
report is that it will try to treat more of the subject than 
time and effort allows. However, any new project manager 
should benefit from studying this report before he starts his 
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project. It is intended that this report also serve the 
other managers such as those reporting to the project 
manager even though they may not require all of the subjects 
discussed here. 



INTRODUCTION 


This report is written from the point of view of a 
major project manager in NASA. With a small adjustment, 
it can be used by any government manager of a major project. 

In fact, industry project managers should find the report 
useful, as should government managers at other levels. It 
must be emphasized that it was necessary to focus on some 
level, and the project manager was chosen. This does not mean 
that he is the only important manager to talk about or the 
only one who can use this handbook. It simply means he was 
the focus. Subsystem, line, staff, center, industry, and 
other managers are just as applicable. All headings may 
not fit each one, but most items discussed will apply to 
all managers. 

In writing the report, it is recognized that a very 
large percentage of managers of major projects are engineers 
who come directly from engineering activities. Usually by 
the time upper management recognizes the aptitude of these 
engineers for a senior management role, there is not time 
for any formal training. Recognizing the need for the new 
project manager, the skill he has demonstrated in related 
jobs and the fact that he has probably observed other projects, 
he is generally congratulated and started rather suddenly. 

Since he is intelligent and a good engineer, he can do this 
job. He can do it more effectively if he has some guidelines 
to follow. There are many features of management, such as 
budgeting, planning, project decision-making, etc., for which 
he may not have any training. Some areas he may not even 
like, i.e., engineers and budgets are not always homogeneous. 
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What is disliked, though, is often that which is not understood 
If a project manager becomes a budget expert, he will probably 
begin to like the budgeting process. In a report prepared for 
NASA by the National Academy of Public Administration, it was 
noted that NASA senior managers who were engineers, parti- 
cularly disliked budgeting, reporting, and fire fighting. 3 
This is natural and they are not the types of jobs an engineer 
has been taught to do. More difficulty was found in planning 
and policy making. It was also noted that three times as 
many skills are needed in management positions as in average 
engineering positions. The importance of these skills showed 
that engineering managers rated operating within the organi- 
zational system and with diverse people, together with decision 
making, as most important. "Achieving” more in management 
was the feature that satisfied most engineers. 

When you consider what has been studied and written about 
management, as discussed in the Preface, and when you realize 
that most managers are engineers with little management 
training, there appears to be a lot of subject matter that 
should be introduced. One report such as this cannot hope 
to attack the whole problem. So what needs doing most? This 
report will attempt an overview of practically all of the 
subjects with which a NASA project manager will be confronted. 
These subjects will be coupled with numerous suggestions as 
to some of the things that ought to be done with each subject. 
Lastly, the subjects and suggestions will be interwoven with 
a philosophy that will be carried steadily through the report. 

It is recognized that this report will be read by gifted 
project managers who will take issue with many of the sug- 
gestions or even the philosophy. This is accepted. What 
can this report tell a project manager who was once a sub- 
system manager about managing subsystems? Probably nothing! 

In fact, project management is an individual thing. No two 
will go about it in the same way. There could be no set of 
rules which would satisfy everyone. However, if your imagi- 
nation on each subject is stimulated to agree or disagree 
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so you make some suitable decision or take some action, then 
the author is more than satisfied. 

Let us discuss the overall philosophy first. In a nut- 
shell, it is that you cannot "passively" be the manager of any 
major project. You must be aggressive; you must be on top 
of all facets of the project. To do this, you must seize 
the initiative at the beginning, with everyone connected 
with the project. You are the expert on that project as a 
whole, and you prove that by leading, not following, the 
project. It can be comforting to sit in your office all 
day and have the day filled with others bringing decisions 
for you to make. But, remember, they are then determining 
what you do and are recommending you do each thing their 
way. That is why they came to you. Probably the biggest 
mistake in big projects which is made by the manager is 
"never catching up with his project". His organization keeps 
him busy bringing the project to him instead of him deter- 
mining what is important. You should decide what is acted 
upon and in what manner. This does not mean you should not 
take advice. Using key advice properly will be the key to 
your success. It means you should make clear who is manager, 
where central project direction comes from, and that you know 
what you are doing. 

If you believe this, then the question is how do you 
seize the initiative at the beginning? That is what this 
report is about. It is believed that if you have the con- 
fidence to be convinced you are not overlooking important 
features of your job and that you are asking the right ques- 
tions, in time, then that confidence will carry through your 
project. Therefore, instead of trying to discuss your pro- 
blems in some chronological order, they will more or less be 
discussed all at once. There are several reasons for this. 
First, if you look at the initiation of action on each subject, 
discipline, or subsystem, some action is required almost as 
soon as the project begins. Also, soane projects by their 
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nature will emphasize some areas sooner than others. Then, 
too, the nature of the project manager may change the emphasis. 
Therefore, the project will be discussed without trying for a 
particular order. 

A new project manager should read all of this report and 
then select some subjects and some areas where he initiates 
actions. After these actions are initiated, he should check 
for the next area he wants emphasized. Remember, you are to 
retain the initiative so do not ask ten questions of your 
engineering group and none of your test group, because you 
are starting engineering and not testing. Also, ask that 
parts of the test plan you do not understand be explained, 
or have parts you do not like redone. Otherwise, your test 
group is idle and may begin to think you do not believe that 
testing is important. They will then bring recommendations 
to you that you have not had a chance to study or think about. 

It will take a major effort to become aggressive again in the 
test area. Your initiative will stimulate not only your 
organization but the appropriate segments of industry as well. 
This same approach should be applied to all organizations of 
NASA, who are involved in your project-not just your organi- 
zation. Take the initiative with the center engineering 
organization, with other centers, with working groups involved 
with your project, etc. This will have a further advantage. 

It will change the attitude of you and your own organization 
from one where outsiders are meddling with your project to 
one where they are supporting you, like an enlargement of your 
organization. 

Each project manager is capable of starting effort on 
his project in each part of his and other related organizations. 
However, he is always a busy man! For one thing, he can find 
ready challenges and prompting in this report in all areas 
of project work. For another thing, he will find considerable 
experience collected here. Where he does not have a good 
reason to depart from the suggestions made, he should pause 
and give these ideas some thought. 



Remember this report is aimed primarily at the manager 
of large projects. For small projects several centers have 
provided excellent guidance, such as Lewis Research Center's 
"The Management Control System for Small Contracts” or 
Langley's "Overview of Langley R & D Program Management 
Principles and Procedures" and several others. ’ 5 There are 
several publications applying to large projects, too. However, 
recognizing the scope of these projects and the differences 
required in approaches* these documents are generally related 
to the policy and procedures applying to these projects. As 
such, they are recommended and can be found in NASA Headquarters 
and most of the centers. Typical of these is a project hand- 
book put out by Goddard Space Flight Center. 

In managing large NASA projects, it must be noted that 
NASA has many types of large project^ and there are different 
approaches by different centers. A project on a scout vehicle 
managed by Goddard which manages many such projects will differ 
from a large engine development by Lewis, or a voyager by 
Langley or a manned program by JSC or MSFC. Approaches must 
vary! For some, launching is an integral part of the project. 
For others it is contracted. Man rating is a useless term 
in many projects. Center organizations handle such things 
as procurement, quality, etc., in many different ways. This 
report attempts to recognize this to the extent practical for 
continuity. However, some adjustment must be made for center 
policy and type of project. In fact, although the project 
manager's initiative is emphasized here, some of the things 
discussed here, for him to do, will instead be done sometimes 
by the center. 

I£ as you go through this report, you make notes of what 
should be initiated, you may get the impression that there are 
more things to start than you can possibly handle. Do not 
get discouraged. Remember, there are very few early items 
that you have to spend a great amount of time on personally. 

Make your notes concerning questions to which your organization, 
or others, should provide you answers. 
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CHAPTER I 


THE PROJECT MANAGER'S ROLE 

There are many definitions of project management. One 
by General Sam C. Phillips, Apollo Program Manager is: 
"Management of a Research and Development Program is the 
integration of people into an organized relationship with 
one another, and providing them the environment, processes, 
means, disciplines and guidance to attain a specific objec- 
tive". The challenge is to orient such a complex structure 
into singleness of purpose or objective so that such di- 
versities as facilities, equipment, procedures, training, 
testing, and so on are brought together properly. Technical 
know-how is essential. Projects flounder or fail if the 
right technical know-how is not brought to bear in a timely 
fashion. 

A project manager must sell his project in many ways. 

He must create his market by keeping his superiors, sub- 
ordinates, and the outside world satisfied that his project 
is progressing properly toward worthwhile objectives. It 
has been said that management is accomplishing what you said 
you were going to accomplish and management is judged on 
whether the objectives were achieved within the constraints 
of time allowed or money allocated. 

Capable people must be given every chance for success 
by providing them a structured environment in which to work. 
Structured does not mean rigid, cast in concrete. It must 
be flexible with only the objectives remaining rigid. However, 
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a perfect organizational structure without the initiative and 
leadership ol the project manager is not a structured environment. 
This is another reason why training would be so useful to a Project 
Manager. Since Management often does not train the right people 
in time, an expectant Project Manager should seek concentrated 
training. A course such as Goddard’s Research Engineering Manage- 

Q 

ment Exercise (GREMEX) takes less than two weeks. Back to organi- 
zation, the structure must be vibrant so that the system engineers 
can identify the way in which hardware, software, facilities, 
people, and procedures will be put together to achieve the ob- 
jective. They also define the technical requirements of the 
pieces. Alternate processes and approaches must be studied. Once 
an approach is adopted, detailed performance and design require- 
ments must be generated. Quality, test, reliability, maintain- 
ability, and other features must be stipulated. Spares and 
logistics must be planned. It is only after these many 
features are thought out and a detailed definition of the system 
obtained, that design, manufacture, test and reviews can be 
firmly started. To thus get a complex organizational structure 
started properly is a difficult task. The way this is accomplished 
is by developing a detailed plan of approach, usually the project 
plan. Then the elements of that plan are assigned to all of 
your people and to other organizations having the required know- 
how, to prepare the plan in detail for your approval. Attention 
to detail is maintained throughout so that problems can be 
identified early and timely action initiated. Then, a disciplined 
approach is developed for measuring progress and making changes 
when necessary. As can be seen by the above initial actions, 
much of the early part of the overall task will fall to the sys- 
tems engineering group. Everyone should participate in the 
details . 

In discussing the overall project manager's role, the above 
provides one frame of thought. A 1967 NASA Headquarters publi- 
cation describing Apollo management, identifies the five elements 
of the management system as requirements definition, require- 
ments implementation, management information and communication, 
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management decision process, and management review/ The first 
oi these establishes objectives, plans, schedules, resources, 
costs, procurement and performance baselines against which you 
can measure. The second translates these papers-or baselines- 
into actions. The third insures that the right people get all 
the needed information at the right time. The decision process 
includes assessing the information, making decisions and then 
implementing action. The reviews let you assess your own effec- 
tiveness and make adjustments and modifications. One might 
recognize these five NASA categories as analogous to the academic 
categories of planning, organizing, controlling, directing, and 
assessing. 

Requirements definitions, the first element of the manage- 
ment system, is initiated by program documents from NASA Head- 
quarters. NASA general management generally requires three key 
Headquarters documents. The Project Approval Document (PAD), 
the Project Plan (PP), and the Program Operating Plan (POP ). 10 ' 11 ’ 12 
These and the Work Authorization Document (WAD) are a delegation 
of authority to the project manager. These approval documents 
then permit you to write your own baseline of your project, 
such as your project plan. This plan will be further discussed 
as it is a very important document. Even if you are not inclined 
to "paper work", you will find that the effort put into this 
document is well spent. Whatever title is given your require- 
ments documents, they should detail your management requirements, 
your technical requirements and for most NASA requirements, 
your mission requirements. 

The Headquarters PAD defines the scope of the project and 
summarizes objectives, the technical plan, the management plan, 
the reporting requirements, procurement arrangements, and 
schedules and quantity requirements. The NASA Administrative 
Processes Handbook supplements the PAD, particularly in the 
budget area. One requirement in this handbook is for the POP 
which is the internal source document for budget estimates 
used eventually for the Bureau of the Budget, Congress, etc. 

Lastly, the Project Plan is the basic plan for the execution 
of the project defined in the PAD. The Project Plan is both 
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a requirement documentation and an implementation plan. It 
is the single authoritative summary of the management technical 
execution and the mission operations of the project. It is 
written by you and will be the document of prime interest 
to you in writing your own requirements documents. It will 
initiate the project baseline in such areas as project 
schedules, hardware planning, change control, key project mile- 
stones, development tests, deliveries, ground support equipment 
requirements, facility readiness data, software requirements, 
the Work Breakdown Structure (WBS) , Government In-House versus 
Out-of-House requirements, contract requirements, and so on. 

The technical and mission requirements can be in great detail. 
Since NASA Headquarters starts the project when you do, it will 
not pay you to wait for the Project Plan, PAD, and POP before 
starting on your requirements documents. You should use pre- 
vious Project Plans, PADs , and POPs as a guide and anticipate 
the requirements with as much prompt work as possible. Positive 
effort on your part will influence these Headquarters documents 
considerably. In fact, good effort from the field will probably 
be welcomed, by the somewhat isolated Headquarters staff offices. 
This is a step in initiative. Also, if you feel strongly on the 
approach in any of the above areas, you will need to exert your 
influence early. 

When you start your own project requirements definition, 
which is usually your own project plan, ask yourself and your 
staff these questions: Who is responsible? Is the organization 

complete and understood? What are the objectives? This means 
what are the technical requirements, usually contained in a 
uniform set of specifications and supporting data given by a 
configuration management approach. These specifications and 
the configuration control probably will require many other steps 
such as baselining all interfaces, writing specifications for 
major subsystems, writing work statements for prime contractors, 
preparing Contract End Item (CEI) specifications, etc. When 
must it be accomplished? Have the schedule milestones from 
Headquarters been broken down sufficiently to assure your control? 
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Do you have and understand a Management Information System (MIS) 
that alerts you promptly to a schedule deviation? What is the 
estimated cost? Do you have a complete schedule of funding? 

Do you have funding control? 

The second element of the management system in the NASA 

Headquarters Apollo document, Requirements Implementation, 

should make you think of your organization. It is the process 

of converting requirements into assignments which direct people to 

act. The first part of implementation is the NASA Headquarters 

13 

Issuance System of key documents. This is a policy document for 
all types of written communications which of course are the 
heart of putting requirements into action. These include policy 
directives, management instructions, notices, handbooks, manuals, 
and directives. The next part of implementation is the contract, 
to include letters of technical direction. These start the con- 
tractor on the requirements. The third is the action item list. 
These may come from all upper levels of management. The fourth 
is formal direction which provides each management level the 
authorization for change or amplification of requirements. Let- 
ters, memos, or teletypes may be used to implement changes or 
amplify work. When properly authorized, standard operating pro- 
cedures and working group action items may implement require- 
ments. The implementation by project directive will be dis- 
cussed in more detail later. 

The third element in the NASA Headquarters system, 

Management Information and Communication, provides the visibility 
necessary to measure project progress against the baseline. 
Visibility demands effective communication and close working 
relationships. These in turn require logical reporting and a 
good management information system. (Choices of information 
systems will be discussed in detail in Chapter IV.) Early 
in the project, you should decide on the depth, manner and 
frequency of reporting you desire from your subordinates. 

There are now a number of techniques for flushing out potential 
problems in technical performance, schedules, and cost. A 
good communication and information system should keep manage- 
ment informed, isolate problems, provide early warning of 
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problems, establish criteria for work around plans, dis- 
seminate information, and promote disciplines and teamwork. 
Currently, full use of the Work Breakdown Structure is 
management's most effective tool. It is a major part of 
all present day information systems. Communication is 
enhanced also by the management reviews at all levels. 

There are literally hundreds of reports that become a part 
of the communication system. Here let us list only the 
types so that you can determine you have coverage in each 
area. These types include project management schedules, 
procurement, contract, data management, configuration 
management, logistics, facilities, manning, financial, 
technical and system descriptions, reliability, quality, 
safety, test, site activation, mission operations, project 
planning, configuration management, and engineering data 
(weight, action items, etc.). Now, you may have several 
reports per heading; you may combine some headings into 
one report; or you may just have some headings presented 
as displays. 

The fourth element is the NASA Management Decision 
Process. Of course, decisions are made from the beginning; 
however, requirements, implementation, and communications 
make decisions vital. The foregoing is of no value unless 
assessment is made and management acts. NASA has described 
the decision process for its APOLLO Project as assessment, 
review, and evaluation action, feedback, and follow-up. A 
key part of this process is the review cycle. You will have 
a prescribed series of management reviews. You will also 
require a system of technical reviews to which you must give 
considerable thought. The technical reviews will include 
some or all of the following formal reviews to serve as 
checkpoints: Preliminary Design Review (PDR) , Critical 

Design Reviews (CDR) , First Article Configuration Inspection 
(FACI), Certification of Flight Worthiness (COFW), Design 
Certification Reviews (DCR) , and Flight Readiness Reviews 
(FRR) . The first four of these are for selected end items. 
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Tho ]ast two encompass the total project. NASA publications 
such as the ATR (Apollo Test Requirements) , the NHB series and 
the remaining NPC series contain requirements for test, relia- 
bility, and quality reviews*?’^Other technical reviews you pre- 
scribe probably will be more periodic in nature and will search 
for and solve problems and will validate the compatibility of 
specs and hardware as set forth in NASA requirements documents. 
Another closely related activity to these reviews and a part of 
the decision process is the configuration management system to 
approve and control changes. This is a particularly active area 
during testing. This system with the direction of assigned pro- 
ject personnel will suitably document change decisions. Other 
decisions that you make should have a means of documentation and 
dissemination, such as by project directives. A particular fea- 
ture of good management is contact - personal conversations, 
closed door sessions, hot line discussions, etc. Don't forget 
that many people need to know the decisions you make in this 
manner, too. Decisions involving schedules and cost are vital 
and will take much of a project manager's time. 

The last management element, Review and Evaluation of Man- 
agement Effectiveness, is necessary, but it is less kin to the 
overall management process than the other elements. To measure 
contractor effectiveness is probably required by the award or 
incentive features in the contract. In measuring its own effec- 
tiveness, NASA is maintaining viability and is insuring the nation 
that its trust is well founded. One center cannot be compared 
directly with another, or one contractor directly with another, 
on an absolute basis, because of differences in degree of diffi- 
culty, type of contract, etc. However, the accomplishment of 
completing the technical challenge on time and within cost re- 
straints can be measured center to center, contractor to con- 
tractor, on a relative basis. Different means of such evaluations 
have been devised, such as incentive evaluation profiles, PERT 
and cost correlation techniques; cost, value, and schedule pro- 
files; and contractor critical reviews. For the immediate 
future, modern Management Information Systems using the Work 
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Breakdown Structure will be essential in measuring effec- 
tiveness. You should study the chapter on these systems 
with some care. The koy checkpoint reviews, POP, CDR, COFW , 
etc., are key technical reviews for assessing progress. 

We have looked at an approach to the project manager’s 
role as suggested by General Phillips and at one covered in 
a NASA Headquarters* publication. Let us look at it again 
from a different direction as a major contracting activity. 

This is consistent even if a major portion of the job is done 
in-house. In most large projects, the bulk will be done 
with industry. Any in-house portion can be considered as 
an in-house contract. In contract management, there are 
two key figures who exercise authority — the project manager 
and the contracting officer. Any delegation starts with these 
two figures. The project manager today is without question 
THE key figure in a large research and development project. 
However, each has spheres of authority in watching for the 
interests of the government. In this case, instead of 
direction from the project manager, the project manager should 
help develop a teamwork approach. Although the goals of the 
two officials may appear to vary at times, the contracting 
officer is really a check and balance for the project management 
He is vital and is needed. Therefore, teamwork will bring out 
the best use of his skill and experience. 

In looking at project management as contract management, 
we can describe the project management cycle as Phased Project 
Planning (PPP), though now somewhat modified. 1 5 These are four 
phases A, B, C, and D which in actual application are allowed 
to vary greatly. A, B, and C are generally Preliminary Analysis 
Definition, and Design. D is Development and Operation. Re- 
lating these phases to contracting, you must first prepare the 
project plan previously mentioned. This will include such 
major features as the technical plan, the management plan, 
the procurement arrangements and the funding requirements. 

One important feature of the technical plan is the Statement 
of Work (SOW). After the project plan is approved, the 
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statement of work will become key in the Request for Proposal 
(RFP). It will behoove you to review it carefully with your 
technical people for content and with your contracting officer 
to see if it requires what you want it to. The contracting 
officer is particularly helpful in determining whether you 
have told the contractor HOW to do this job. This determines 
the control over him that you desire. The statement of work 
covers all aspects of the project, such as design, fabrication, 
spares, reports, and many others. It is here that you form 
your special instructions to the contractor for such items 
as use of configuration management, prescribed use of faci- 
lities, use of developed components, etc. After considering 
the RFP, you must plan the procurement and select or recommend 
the contract type. Then, you conduct the solicitation, 
negotiation, and award phases. Following this is contract 
management where many of the features we have discussed such 
as controlling, measuring, etc., occur. 

One can see that the foregoing requires teamwork. While 
on one hand, a project manager does such things as: determine 

how project work will be done, plan work, and break work into 
manageable pieces, analyze work versus resources, assign 
responsibility for project elements, serve as a focal point, 
review, participate in negotiation to assure common under- 
standing, solve management and technical problems, make final 
decisions within contract scope, give guidance and direction, 
indoctrinate and monitor contractor performance, etc. On 
the other side, the contracting officer administers the 
contract, coordinates specialists during negotiations, moni- 
tors delays and cost changes in reports, receives all contractor 
reports and documents, issues change orders and contract mod- 
ifications, helps delegate inspection and audit to DOD and 
other agencies, approves fee payments, and delegates function 
to on-site representatives. Since these two sets of acti- 
vities are so intermeshed, they must be worked upon together. 

It will reward the project manager to have his team and the 
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contracting team meet, formally discuss, and set up the 
whole ladder of contracts. 

To insure that the project manager understands the 
contracting requirements, he should familiarize himself 
with a number of Headquarters documents, such as "Procedures 

for Contractor Reporting of Correlated Cost and Performance 

X 6 

Data". His contracting officer should have or have access 
to such pertinent documents. 

Thus far, in this chapter, we have discussed several 
approaches to describing the overall project manager’s role. 
Certainly, his role is difficult, challenging, and diverse. 

The scope defies imagination. For instance, the overall 
manager of APOLLO now goes down in history as having suc- 
cessfully managed the largest R & D project the world has 
ever known. To successfully manage one of these large 
projects, you must immediately demonstrate leadership and 
that takes us quickly back to aggressiveness not passiveness. 
You must establish yourself. You have full time jobs in the 
management world, technical world, and the human behavioral 
world. As such, your big problem will be your own time. You 
will work long hours and bring work home. That is expected, 
but it is not enough. What you do with your time is what 
counts. An early step you should take is to budget your time 
This will take considerable initiative on your part. Probably 
the biggest consumer of a project manager’s time is meetings. 
For a major project, where many organizations are looking 
for a time that does not overlap with other meetings, usually 
the entire day is filled with meetings concerning your project 
For most project managers anxious to stay on top of their 
project, a feeling develops that they cannot afford to miss 
meetings concerning their projects. In reality, you probably 
cannot afford to attend them. There are some things that 
must be done each day. If they come after all meetings, they 
won’t get done. You will have a certain amount of mail. YOU 
should determine how much you want to see and how the rest of 
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it is to be handled. You must respond to the behavioral 
world and see and talk to people. You can set up your 
own method. It is suggested you do this by having one of 
the line or staff offices or offices not a direct part of 
your own organization see you at a stated time each day to 
respond to some particular questions you have asked. This 
lets you see all key people, makes the time productive, 
and lets you retain the initiative. Another thing you must 
do is plan. During a portion of every day you should get 
together with a few of your key members and devote time to 
planning. This helps lead you to directing. The meetings, 
planning, contacting, and the suggestions in this report 
will cause a need for directives to be issued. This takes 
time. Allow yourself time to apply your own method of 
getting the job done. This should have some degree of 
formality however, so everyone knows what he is to do and 
so others know who is doing a particular task. Since direction 
results from mail, phone calls, etc., a standard memo record 
of your actions with a set distribution is a good way to 
distribute information without too much effort on your part. 

One method of planning and of keeping up with your project 
is to have a set time — thirty or more minutes — at the start 
of each day for what is known as "The Breakfast Club”. You 
can do some planning and hear of major issues and problems. 
Although not entirely suitable, since many are involved, 
this can be enlarged to be your contact meeting. Be sure 
you have asked written questions at a rate of more than one 
a day and let your project control officer schedule the 
questions for answering one each day. Remember that of 
course the unforeseen will occur-travel , major problems, 
requirements of your superiors, etc., which will encroach 
on your time. Therefore, you must allow more than ample time 
for non-emergencies since some will last. This takes us 
back to meetings. It is a good thing to have a project deputy 
and it is good to develop him as an ’’alter ego” but to have 
each of you attend the same meetings is a nicety you can not 
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afford. You must brief each other. A suggested approach 
on meetings is to have your deputy attend more than you 
do. You arc busier than he is. He can often bo used for 
meetings of higher authority where project management Should 
attend. If you set a pattern and stick to it, people will 
adjust to your pattern — aggressiveness. It is suggested 
you announce you will attend one major meeting a day, pre- 
ferably at a stated time. For other meetings that are consi- 
dered important, it is suggested you send your deputy. It 
is suggested that you also develop an assistant who helps 
you in meetings. Pick someone you have confidence in and let 
it be known that he attends for you. He will of course have 
personal bias in his briefings and recommendations to you so 
this must be done with care. However, such an approach is 
superior to either attending all meetings yourself or to 
handling meetings in some random manner. 

It will take considerable personal effort to budget your 
time. Everything that occurs will seem more important than 
what you are trying to establish as a routine. A work of 
caution, however, a few ’’flaps 1 * that can break up necessary 
project routine are not likely to cause an overall project 
to fail. On the other hand, if a project manager does not 
organize his project properly, a thing that he along can do, 
the project may fail. A project manager must budget his time 
to take care of what is at times, relatively unattractive 
portions of his job. 

Having discussed the project manager overall role and 
the allocation of time to that role, it remains to discuss 
the many pieces, in some detail, that fit into that role. 
Chapters II, III, IV, and V will devote themselves to some 
important major elements that are worthy of separate treat- 
ment. Chapter VI will treat the subsystem and subelements 
of project management. Chapter VII will deal with a series 
of other major decision activities that every project manager 
confronts in his job. Finally, one must devote considerable 
effort to doing the project at the lowest possible cost. 
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CHAPTER II 


REQUEST FOR PROPOSAL (RFP) 

This subject is taken up separately because it is im- 
portant, it occurs very early in the life of a project and 
because it is vita] that the project manager become directly 
involved with the RFP. The RFP should be put in perspective. It 
is one of a series of related steps in developing the project 
contract. However, it is a most important step from the point of 
view oi project management. The procurement steps include: 

1. The process of Project approval 

2. Determination of type of contract 

3. Developing the procurement plan 

4 . RFP 

5. SEB activities and contractor selection 

If possible, the project manager should chair the Source Evalua- 
tion Board (SEB) or at least be a key member on the Board. If 
so, the RFP will be fundamental to the work of the SEB. The RFP 
is the first and a very important step in the determination of 
the project contract. You will have to live with that contract 
for years. Anything you can do to build the contract properly is 
worth doing. It has been said that the NASA aerospace 
experience has developed a philosophy which recognizes the 
benefits to NASA and to the industrial company of an unambi- 
guous definitive contract work statement. The work statement 
clearly states objectives and acceptance criteria for all 
elements of the project, from overall goals to details 
affecting the work in the shop, to forthright recognition of 
the integrity of the profit motive. Real motivation is established 
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by the contract for those goals most important to NASA. 

Of course, the government interest in the contract is 
equally high. It will establish your contractor working 
relationship as well as the subcontractor arrangements. 

Any oversight committed must later be purchased or done with- 
out. Your ability to further define the project, review the 
progress, measure the work done, correct the problems and 
direct the correction of deficiencies are all dependent on 
the contract. 

Formally, much of the effort in this state of the project 
is accomplished by the contracting officer. However, the pro- 
ject manager is responsible for and should want to decide on 
the special provisions in the contract, the reporting categories, 
the requirements schedule and financial information, the state- 
ment of work, and many other features. 

Most of the centers have collected pertinent procurement 
information just for the purpose of assisting managers develop- 
ing a procurement package. You should become generally familiar 
with this information. This guidance generally includes a list 
of points of information to be considered for inclusion in the 
RFP. This is a particularly helpful checklist since it is 
designed for your own center. 

All of these, including the selection of the type of con- 
tract, are worthy of project management attention. There is no 
one right answer to the procurement and contract activities. 

There is instead a best answer for the nature, peculiarities 
and timing of your particular project. It needs study and ex- 
pert advice. The project plan, generally required before the 
process of obtaining project approval is started, should be 
written so as to be the basis for the RFP. It follows then that 
the project manager should be on board during project approval. 
Because this commits a key man before approval is known, for 
large projects, he is often selected later and must catch up 
during the RFP. This is avoided where he is also the study 
manager. 
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It is NASA policy to give all qualified sources equal 
opportunity to participate in procurements. The RFP then, 
which includes the statement of work, describes the work 
to be performed and the terms and conditions under which 
the government is willing to enter into a contract. Thus, 
the quality of the RFP will determine directly whether 
comparable and pertinent information is received from com- 
peting offerers. The RFP also has the objectives of obtaining 
from the offerer as much data for review and evaluation as 
are reasonably available and necessary. In order that the 
proposal can be evaluated and costs controlled, care must 
be taken not to ask for unnecessary information. The pro- 
cedures for and the handling of RFP T s and responses, by the 
SEB, is a subject by itself. If you are unfortunate enough 
to chair an SEB before you have served on an SEB, exercise 
great care. You will require many briefings, and considerable 
reading. 

This care with respect to RFP’s is one reason why lead 
times are so very long. Even after completion of the technical 
and management packages and through contract award many 
months are required. You must plan for this in your sche- 
duling. 

The RFP is generally prepared with major assistance 
from the cognizant procurement branch and guidance from the 
project office. It is generally written so as to require a 
response in two major parts, a management plan and a technical 
plan. It also includes qualification criteria so unqualified 
sources will not bid. It includes evaluation criteria 
described as to their relative importance. It also includes 
such things as preproposal conference details. 

The project manager is most concerned with the manage- 
ment and technical plan. The statement of work must 
be written so clearly that both government and contractor 
will understand the expected results and the items the 
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government intends to buy within technical and quality 
specifications. The SOW must be individually tailored to 
suit all peculiarities of the work to be performed. It 
must also take into account the type of contract to be issued. 
A good SOW will enable the project manager to evaluate the 
performance of the contractor. Such evaluations will be 
vital to you throughout the life of the contract, to insure 
satisfactory performance by the contractor. When special 
fee evaluations are required, the award or incentive fee 
criteria for these evaluations must be established in the 
SOW. 

Statements of work may cover the contractor for a variety 
of work and thus the work done on the statement of work 
will affect directly all contract phases. From a government 
point of view, one must always remember you cannot change 
the contract as advantageously after it has been negotiated 
as you can just include the item in the first place while it 
is under competition. The SOW may cover analysis, feasi- 
bility studies, supporting research, study tasks within 
project phases, hardware development, production of limited 
quantity hardware, modification of a limited quantity of 
standard hardware, special test equipment, ground support 
equipment, launch or flight services, management and engi- 
neering services, and so on. 

Thus, the requirements or tasks for the SOW may vary 
widely; however, many elements are common for all statements 
of work. The SOW will be separated clearly into tasks. If 
a level of effort service is to be provided this must be 
specified. If it is a cost reimbursement type of contract, 
your technical direction must permit trade offs, alternate 
choices, etc., within the contract scope. You are permitted 
to direct, generally, the contractor counterpart organization 
to provide team performance with the government at least 
cost. The SOW is your opportunity to do this. The basic 
elements of the SOW 2 
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a. describe the work to be done, 

b. any special instructions to how the work is to 
be done, 

c. information to help understand the SOW, 

d. various appendices to amplify any parts desired. 

In another area, the SOW includes background, objectives, 
scope of work and specific tasks. In some cases, background 
and objective statements are also added. 

The scope of the work covers what is to be done by the 
contractor to meet the objective. It is a summary of 
requirements stating what is to be furnished by the con- 
tractors, the class of effort involved and the extent of 
the work to be performed by the contractor. This scope is 
general and should not include any specific tasks which are 
priced,. The items to be furnished by the contractor may 
include personnel, facilities, materials, services, equip- 
ment, etc. The effort by the contractor may include study, 
analysis, design, evaluation, fabrications, instrumentation, 
examination after testing, preparation, shipment, etc. The 
extent of the work is described by specifications; therefore, 
design and performance specs must be written with care. 

It is the specific tasks that delineate what work is 
to be performed and priced. These tasks provide the details 
of what the contractor is to do. All work which is priced 
must be in this section. This is the section the contractors 
engineers and price analysts will work with in making a pro- 
posal. The negotiated price of this section with any work 
added later will determine the price of your project. If you 
omit major work, or estimate poorly the price of these tasks 
or fail to describe them adequately so that the contractor 
can not be held accountable for the proposal, an overrun 
will be imminent. A list of typical tasks that could be 
included in the statement of work are; 
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a. Management (project management, schedule, co- 
ordination, configuration management, cost control, 
reporting, etc.) 

b. Development of components, subsystems, and systems 

c. Study and analysis 

d. Design and design maintenance 

e. Fabrication and assembly 

f. Inspection 

g. Conceptual design 

h. Documentation 

i. Test plans and testing 

j . Design review 

k. Building prototypes, mark-ups, and special test 
equipment 

l. Instrumentation 

m. Providing spare parts 

n. Design, fabrication and maintenance of special 
equipment, tools, and fixtures 

o. Design, fabrication and testing of ground support 
equipment 

p. Preparing for delivery 

q. Providing Reliability and Quality Assurance (R&QA) 

r. Reporting 

s. Special Tasks such as value analysis 

Reliability and quality assurance are usually established 
in a special section where the NHB series is tailored to 
your project. However, any special provisions such as in- 
spection you may desire are included in this section. Some 
voluminous tasks, such as reporting, are sometimes placed 
in the appendix. 

Performance specification should be given some thought. 
These specs can be a number, a variable or a range, in order 
to express physical characteristics. They should be firm, 
but they may have to be goals, or minimum levels. Uncertainty 
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in state-of-the-art in large projects cause goals with 
minimum acceptable levels to be used, i.e., , a material to 
maintain a certain tensile strength at temperatures where 
the goal is 2500°F and where 2000°F is a minimum acceptable 
level. If you require the goal you must in some way incen- 
tivize the contractor to achieve it. This is a cost element. 

Of course, the remainder of your design remains uncertain 
until you know at what temperatures you can operate. Therefore, 
if possible be specific on performance. 

The purpose of special instruction in the RFP is to 
establish the ground rules you use for the previous specific 
tasks. They are not cost items but they affect cost. A 
specific configuration management technique is a special 
instruction. Also, areas specifying use of equipment, com- 
ponents, and hardware previously qualified can state that 
the contractor will use certain existing facilities and 
resources. You may want him to refrain from providing ser- 
vices during times of duplication with government or other 
agencies, such as during part of the flight. 

In preparing the SOW, the project manager should identify 
the end items required, a clear definition of the objectives, 
the specificness or flexibility of the SOW, the contracting 
approach, and the work breakdown structure. It is suggested 
that you break down the package for writing and become 
the devil's advocate. Review each package from both the 
government and contractor point of view and critique each 
portion with the writer. It is suggested you set up a 
checklist under major headings. For the technical speci- 
fications, is all performance considered; are both design 
and performance covered; are variables and ranges specified; 
are test points adequate; are all test specs included; are 
materials specified; are drawings and specs covered; etc.? 

For performance management are reporting requirements indi- 
cated; are major schedule points defined; are decision or 
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technical approval points indicated; can point of compliance 
with SOW be established; are inspection and acceptance points 
sufficient; are performance features susceptible to incentives, 
etc . ? 

For clarity and form, are specs and reporting requirements 
clear; is the government’s response to submissions clear; are 
there conflicting statements; are tasks separately labeled; 
is the sequence logical; are cross references accurate, etc.? 
Office of Manned Space Flight (OMSF) , Lewis, Goddard, and 
others have published good information on specifically how to 
prepare the RFP and SOW step by step. The NASA Management 
Instructions (NMI's) can help you, too. 

If you will organize the entire RFP in this way, develop 
checklists, and critique the various packages, you will 
develop a good clear RFP. The effort spent here will serve 
you well in the coming years, if you and the contractor both 
know from the beginning exactly what the RFP requires. The 
work involved will interface you with all parts of the project 
and with the technical areas, contracting areas, and your 
own organization. This being early in the project, it allows 
you to demonstrate your initiative and control and learn your 
project. 
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CHAPTER III 


THE PROJECT PLAN (PP) 

The prime foundation of any project is its own complete de- 
scription and its goals. The Project Plan is given separate cover- 
age because, after you have completed contractor selection, your 
planning or the project plan is the Bible or the basis of your 
future. The Project Plan is originally written before contractor 
selection, so much of the work, has been done. Once a contract 
is underway, the Project Plan is seldom sufficient without some 
modification. It isn’t suggested that now is the time for many 
contract changes. Instead, you will have learned of new check- 
points and above all you will be able to pinpoint responsibilities. 
This is the time then to amplify, expand, and define your plan in 
detail. The first planning action you take is to define what is 
going to be done and record it in a project plan. This estab- 
lishes requirements and serves as a baseline against which you 
can judge progress as the project progresses. Your plan is the 
WHAT, the objectives and requirements, the WHEN is the list of 
checkpoints all through the project, and the WHO tells you who 
is responsible for each and every part of the project. A major 
mechanism for doing all of this is the work breakdown structure 
you have already established. This permits clear assignments 
without overlap. The cost planning features of the work breakdown 
structure must be worked out in detail. 

Now at this point, you may well be a little confused. What 
is this new big plan suddenly? It sounds very much like the 
Requirements Plan we discussed at the beginning. Or, at least, 
it sounds like the Management Plan, the Technical Plan, and 


26 



the Statement of Work. The truth is, it is highly related 
to these previous steps. In fact, il’ you have done your pre- 
vious work well, the Project Plan will not be a difficult step. 

The Project Plan, Procurement Plan and Project Approval Document 
are the basis for your project and the first documents prepared. 
The contractors response to the RFP deepens these documents. All 
we are talking about now that those documents are approved is an 
updating of your plan, deepening it for internal use and making 
clear the "what, who and when" for the project duration. 

One way you can plan is to think of each major element of the 
project and assign it for execution or planning to a segment of 
your own office. Then have each of your offices write project 
element plans. Since these assignments would fall more to staff 
offices, you will probably have some hardware development offices 
which are in the position to carry out these plans. If so, you 
must coordinate carefully. Such an approach might look like this: 


Project Element 
Management Plan 
Schedule System Plan 
Procurement Contracts 
Documentation Plan 
Equipment Management 
Logistics Support 
Facilities Plan 
Manning Requirements 
Financial Plan 
Technical Requirements 
Rel. & Qual. Assurance Plan 
Master Test Plan 
Launch & Mission Operations 
Data Interchange Plan 
Growth Potential Plan 


Responsible Office 
Project Control Office 
Project Control Office 
Project Control & Contracts 
Project Control/Data Management 
Systems Engineering & GSE 
Systems Engineering 
Project Control Office 
Project Control Office 
Project Control Office 
Systems Engineering 
Quality Office 
Test Office 
Operations Office 
Project Control Office 
Systems Enginering 


Of course, there could be others; and there will be some 
care required in preparing and monitoring these plans. 

Another approach to planning and one more normally used 
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is to prepare an overall Project Plan. This approach might 
not involve the stall’ oilices as directly, and assigned 
responsibility might not be as clear among the staff offices. 
It would have several advantages, however. The coverage 
should be more complete and the plan should present a more 
unified approach. Also, it would offer a better opportunity 
to have more offices — to include some not in the project 
office, directly involved in assignment, as opposed to a 
single office per task. We think of the Project Plan as 
reflecting the project manager's understanding of the 
execution of the project, as it is accomplished, mostly 
by the contractor. It is however, also the reflection of 
the agreement between the center and the NASA Headquarters 
Program Office. The funding, its rate of availability and 
exactly for what the funding is to be spent, must be under- 
stood among all NASA offices concerned. Present practices 
to lengthen the project definition phase, sometimes with 
additional studies, should further this understanding. 

Since a Project Plan is now available for most projects, 
a good way to start preparing such a plan is to pick a project 
similar to yours and study its plan. If you hurriedly follow 
another plan through, you will neither improve on it nor af- 
ford it the understanding it deserves. Developing such a 
plan is another opportunity for you to assert yourself ag- 
gressively. The vital work on the Work Breakdown Structure 
will assist you with your Management Information System. 

Completeness is a key note of the plan. Although each 
plan should vary, listed below will be a typical table of 
contents for a rather complete Project Plan of a large 
project, as a checklist: 

a. the summary includes objectives manpower, funds, 
justification, history and related work; 

b. the technical plan includes approach, problem 
areas, design considerations, man rating of applicable 
projects, systems engineering, reliability, human engineering; 
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compatibility, standardization, transportation, logistics, 
producibility , mission description, vehicle description, 
description of each major hardware element (to include 
structure, propulsion, electrical, instrumentation, flight 
control systems, mechanical systems, ordnance and ground 
support systems), C onf iguration M anagement (CM), organization, 
CM Identification, CM Control, CM Accounting, master test 
plan, ground tests, and flight tests; 

c. the reliability and quality assurance includes 
organizational responsibilities, general requirements, 
numerical requirements, project requirements, NASA Head- 
quarters requirements, R & QA Plans, R & QA disciplines; 

d. the management plans cover the requirements of 
higher management, the duties and relationships of various 
offices (to include other centers), the center technical or 
laboratory areas, the project manager’s office, the admin- 
istrative office, resident offices, project control, test, 
operations, systems engineering, reliability and quality 
assurance, and hardware offices. It also describes the 
contractor relationships. Finally, it gives a baseline 
definition against which progress will be monitored. The 
subelements in this baseline resemble the planning elements 
previously described in this chapter. This baseline will 
also have descriptions of performance measurement and analysis, 
management reporting, project control and project directives; 

c. the Project Plan will also include various manage- 
ment reporting methods, such as contractor to project, 
project reporting, financial reporting, reporting to NASA 
Headquarters, Management Information Systems reporting, 
periodic reports, film reports, and data management; 

f. the procurement arrangements include organization, 
procurement plans, contract award cycle, negotiations, 
contract modifications, and a description of the major 
contracts in the project; 
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g. the schedule section describes the scope, major 
milestones and schedule control by the management information 
system; 

h. resource requirements describe the approach, identi- 
fication, justification, authorization, design, construction, 
operations, maintenance, management, descriptions of all 
major facilities used in the project, ground support instru- 
mentation, project support requirements, instrumentation 
requirements (to include meteorological tracking, communica- 
tions, telemetry, and photography), transportation require- 
ments for all facets ctf the project, project funding, planned 
obligation and expending of appropriated funds, manpower 
control funding, manpower forecasts, and budget reporting; 

i. the section on operating plans is mostly concerned 
with coordination. There is contractor responsibility, 
inter-center coordination and intra-center coordination; 

j. lastly, the logistic section covers logistics 
support planning, logistic support requirements, concepts, 
maintenance, maintenance support, maintainability, maintenance 
evaluation, spares, supplies, provisioning, maintenance 
instructions, field support and training. 

You can see the Project Plan is intended to plan for 
every phase of the project. If you plan well, you will find it 
is much easier to adjust from a well ordered plan than to 
scramble to cover items which have been overlooked. It is 
not expected that a busy project manager will write the 
project plan. You should not or other things will be slighted, 
but if you decide what is in the plan and review it systema- 
tically, your initiative will be felt. 
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CHAPTER IV 


MANAGEMENT INFORMATION SYSTEM (MIS) 

Many portions of the project manager's job are relatively 
obvious, i.e., planning. Regardless of whether your planning 
is complete or timely, there is little doubt you would be aware 
of the early need for some planning and that you would do some 
planning. On the other hand, quite often project managers let 
the requirement for the establishment of a Management Information 
System (MIS) slip by them until the planning must be rushed. 

Of course, a requirement for a MIS is a contractual require- 
ment. It should be covered in the initial contract negotiation, 
if at all possible, but could be added contractually at a later 
date. It is generally NASA's practice to specify the WBS 
levels and make-up and to specify certain areas of compatibility 
but not to specify the exact MIS that the contractor will use. 
Actually, it is not necessary to specify the contractors sys- 
tem in order for you to use any type of system you desire, 
but it is usually desirable for you to use the same system. 
Specifying the WBS in some detail and certain features for 
compatibility will give you flexibility. It is necessary that 
you specify at an early date that the contractor use some 
system compatible with the system you require for yourself. 
Hopefully, you can do this without changing his system. By 
doing these things early you will insure that the contractor 
information flows to you as soon as the project begins and 
that you will have the system to absorb, analyze, and control 
the project from the beginning. 

Actually, the selection, development, and use of a 
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management information system is a fairly sophisticated 
process. There may be a decided advantage in changing the 
type of scheduling system, for instance, for different 
phases of the contractor's development program, particularly 
if it fits the contractor's system better if you do change. 

These systems have progressed to where they range from 
fairly simple approaches to complicated, state-of-the-art 
approaches. You must realize, however, that some projects 
today are quite complex and push the state-of-the-art. It 
is virtually impossible for a project manager to oversee 
and direct such projects without some sophisticated help. 

If you have a large complex project you should study today’s 
MIS and consider one suitable to you and your project. It 
is preferable that you and your contractor use the same system, 
if it satisfies your purpose and his. Though you do not want 
to dictate the system he uses sometimes he has enough lee- 
way that you can agree on a single system. Sometimes you can 
not. The following may help you sort out the choices and take 
the necessary steps should you have to embark on a separate 
system. 

Management Information Systems began to reach a sophis- 
tication commensurate with the technology level of the projects 
in the late 1950' s. One of the first such systems was PERT (Pro- 
gram Evaluation and Review Technique) which was the basis of 
management of the complex POLARIS project. PERT could still 
be used more today. It was invented on POLARIS, was learned 
thoroughly by everyone from Admiral Raborn on down, and it 
generated considerable enthusiasm on the project. If it 
does not work as well today, it is partly due to technology 
change, but mostly due to the fact that PERT is taken for 
granted, assumed to be understood by all individuals, and yet, 
is not really understood by all. For a MIS to work, all must 
thoroughly understand it and believe in it. You, as project 
manager, are the only one who can cause that to occur. With- 
out your leadership, enthusiasm, and involvement, any MIS 
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will 1'all to specialists and the treatment will become 
mechanical - and Jail. You cannot leave your MIS to spe- 
cialists. The driving l'orec must be you. One of the main 
problems with the many systems developed recently is that they 
are developed by specialists for use by specialists. Many 
studies have been funded by NASA to further the MIS technology 
but little involvement by project managers has occurred; 
therefore, the systems are somewhat sterile. 

For completeness and for your consideration some of the 
more advanced systems will be listed here. After PERT came the 
Air Force's C/S PCS (Cost/Schedule Planning and Control Specification) 
The C/SPCS, as do most modern systems, utilizes the WBS , and 
stresses having the sum of the internal budgets equal contract 
costs. Here the Air Force, and contractor use the same system. 

The Air Force has developed this system by using it on several 
major projects. A major disadvantage, as with most new systems, 
is that it is not easily understood by project management. The 
Air Force has taken the time and effort to insure that their 
managers do understand C/SPCS and make it effective. 

Another system is MSF/DPS (Manned Space Flight/Data 
Processing System) . This system is a fairly complex soft- 
ware emphasis system where a user rapidly assembles tailor 
made application to assist in decisions. A system which 
preceded MSF/DPS was AMIRS (Apollo Management Information 
and Retrieval System) . A second phase of AMIRS was MAIDS 
(Management Automated Information Display System) . AMIRS 
and MAIDS were then combined into one system known as MINE 
(Management Information Network Extension) . AMIRS was a 
means of querying, abstracting, and summarizing files of data. 

MAIDS was an on-line visual display system. Together, as 
MINE, they were a complete computer software system, but 
complex. Another system of this period was MIRADS (Marshall 
Information Retrieval and Data System). This, too, is a 
software package using a computer to generate reports from 
a data base. This could be described as the period of the 
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specialist whore specialist developed system after sophis- 
ticated system using some form of processing programs and 
control tables as well as software language such as Fortran, 
Cobol, Assembly, etc. Models of these systems were placed 
on managers' desks and impressive data punched up for him. 
However, managers did not understand the systems and were 
unwilling to turn this much of their management over to 
specialists. Before this fact was accepted, however, systems 
advanced until they could include these characteristics: 

a . a tutor assistance program 

b . a quick look capability 

c . resource analysis 

d . mathematical analysis capability 

e . file management capability 

f . random access 

g. direct access of fields 

h . formulated outputs 

i . on-line and remote capability 

j . retrieval and up-date capability 

k . user defined formating 

1 . transferability 

m . multi-file capability 

n . independent source language 

o . conversational language capability 

p. immediate access devices 

q . micro language for use in files 

r . regenerative files capacity 

s . optimal usage capability to filed level 

t . text editing 

u . data integrity and access right 
v . flexibility 

It is apparent that the computer and software experts 
have pushed the MIS state-of-the-art, but the complexity 
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and the flexibility to do everything overwhelm most managers. 
This situation has caused ’’User Manuals” to be developed 
in depth. However, these must be written for specialists 
because the usage is complex. 

The points made above are typical of most modern com- 
puter-software MIS. Some of the other existing systems 
are Burroughs Corporation's FORGE, U. S. Army's RAPID, 

Overbach Corporation's DM-1, Computer Science Corporation's 
TDMS, Scientific Data Systems Corporation's 9 SERIES MANAGE, 
General Electric Company's IDS, Information Incorporated's 
MARK IV, International Business Machines Corporat ion ' s GIS, 

The National Military Command System Support Center's NIPS, 
and DOD's SAIMS. These are general systems intended to have 
access to any User's data base. In addition, most large 
companies, North American Rockwell, McDonnell Douglas, Boeing, 
etc., have specialized systems intended for their own 
internal management and available if you want to accept 
their systems as is. Unfortunately, there is little usage 
of such systems by the managers of large projects. 

We might pause here and draw a few conclusions regarding 

MIS : 

a. We do not need to advance the state-of-the-art in MIS. 

b. MIS will not succeed in a large project unless actively 
used and understood by the managers. 

c. The project manager does not need all of the MIS 
capability nor all levels of information available for his 
own use . 

d. The project MIS should reflect the manager’s mode 
of operating. 

e. Effort should be expended to make the computer dis- 
play a live thing, easy to manipulate, instead of a cold 
complex cathode ray tube. 

f. Usage and user's manuals should be built for both 
the manager's level and the staff level. 
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Unless you are a computer expert or have the time and 
talent to delve into modern systems these features will be 
a necessity. 

The foregoing might appear to paint a bleak picture 
and cause you to want to do without a MIS. Do not draw that 
conclusion too quickly. A good MIS may be a necessity in 
today’s complex projects. True there are some false starts you 
can take, but this has been recognized in some parts of NASA. 

The lack of usage of sophisticated systems has been noticed. 

NASA has let contracts with General Electric and others to 
produce a usable system. The WBS is still considered vital. 

The other steps have been not to overcomputerize, to develop meth- 
ods of measuring performance against both the planned and actual 
by WBS, and to push the visibility of such a system forward 
by relating budget and schedule to performance. One system 
for doing all this is called PMS (Performance Measurement 
Specification). Unfortunately, no program funds were allocated 
so that NASA did not complete development of a general use 
PMS System, but they were on the right track since credibility 
of performance measurement, has always been a disruptive pro- 
blem. Relating performance — or problems — to schedule and cost 
data is another necessity. These things can be done without 
over-computerizing the system. However, the system, to 
provide the data you need, will still be complex. It seems 
to work best when the MIS is engineered in two parts, a top 
down version for you and a bottoms up version for the staff 
levels. These parts must be compatible, but each of you will 
then have a part where complexity and detail suit your require- 
ments. You can each learn your systems in detail and the 
checking of one against the other will stimulate general use. 

This is a better way than just using the top charts of one 

overall system where the overall complexity must be under- 
stood by all. 

Now how do you get there? It is possible that by the 
time you read this NASA will have developed a good general 
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purpose MIS lor project managers. This is doubtful, however, 
both because of the austere nature of today’s budgets and 
because of the different and individual natures of project 
managers. If your project is small and sparsely funded, 
you will have to adopt some existing system, PERT or the 
Control Room technique. You will be somewhat handicapped, 
however. If you can fund two or three manyears of effort 
and your project is complex, you can obtain an experienced 
contractor and adapt a system to your own use. A good way 
to go at this would be to inform the contractor, telling 
him what you want by RFP or other suitable approaches. Then, 
tell him the time scale and what you are willing to pay for 
implementation. Have the contractor come back in about three 
weeks and generalize the options available to you. Choose 
one of these and have him adapt it to your project. 

The above approach can be carried out rather quickly. 

The need for an MIS occurs early so that your people are 
involved with many other aspects of the project . in addi- 
tion, it is unlikely that you have a sufficient number of 
specialists to develop a system, but they can at least do the 
initial conceptual work. It is for this reason that modest 
contracting is in order. The keys are to know what you want, 
select a capable contractor and do not let the contractor 
get lost in advancing the MIS state-of-the-art. You prob- 
ably should ask for some internal briefings first so that 
you form your desires and understanding. This will also 
get your own and center people involved and develop enthusiasm, 
so necessary for a successful MIS. You must initiate the 
action. If you do not, someone will note that you have no 
such system and make some proposal. 

It is recognized that this chapter has emphasized 
Management Information Systems. At least, it is hoped that 
it has portrayed some of the history and problems. If you 
have a large complex project, you will need a system in 
order to track and measure progress. If your contractor 
does not have a suitable system you must understand how 
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you want to proceed. It is always preferable to use his 
system, but his system will be adapted to his needs, not 
yours, and will be complex. Since you will not start with 
equal knowledge, there is doubt at least that you will ever 
learn his system to the extent necessary. 
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CHAPTER V 


PROJECT ORGANIZATIONAL THINKING 


It has been said that a project manager's environment 
is a "veritable sea of information, coupled with a myriad 
of constraints, and a constant need for decisions and 
actions". In this apparent confusion you are expected to 
insure proper emphasis among technical performance, cost, 
and schedule so that you achieve total success and stay with^ 
in your constraints. We have discussed some early 
necessities to the project, the overall look, the con- 
tract award, the project plan, and its information system. 
Before we discuss subelements of the project, let us assess 
where you are. The initial rush is over, and we are barely 
underway. To get here you had to have an organization and 
do some project and organizational thinking. However, some 
events have now occurred. 

Your project has a slightly different nature now and 
you want to be sure your own organization is still right for 
it. Procurement procedures should now be understood. The 
project is now defined and "sold" so there is less emphasis 
on trade offs and analyses. You have a plan and you must 
now adapt to it and execute it. Another event is that you 
have had time to assess your organization and your people. 

You understand better how they function, what you may expect 
and what you cannot count on. Lastly, you have had a chance 
to look at yourself. It is difficult to make yourself realize 
the effect that you have on your project, particularly if 
the project is coming to you instead of your leading the 



project. The personality of any manager, good or bad, has 
a major effect on any project. Also, if it appears to you 
that this is not so, that anyone could have sat in your 
meetings today and nodded "yes" at the end, then look again 
at your aggressiveness. The project is not getting all it 
can out of you. The decisive steps, remarks, memos, telephone 
calls, reluctance if necessary, and direction that comes 
from you and you only will be discussed in the halls and 
offices. They will set a tone and direction for the project. 
They can cause a buoyance and an esprit to exist. These 
things are necessary. Although it is hard to prove, such 
approaches recall the saying, "A decision, though wrong, 
made decisively and in a timely manner is better than no 
decision at all". 

Yes, it is the right moment to reassess your organization 
and some of the thinking that goes with it. The above dis- 
cussion of what has now passed may seem to indicate you are 
less busy. Of course, this is not so. You are never less 
busy. Nevertheless, some time spent looking at the organization 
may be very worthwhile. As usual, you should initiate some 
action and not try to do the work yourself. Then, you must 
take time to assess the result. By this chapter and by your 
own observations you can no doubt list some questions regard- 
ing your organization that have entered your mind. List them 
and have your staff coordinate them and bring you some recom- 
mendations. There are a number of areas worth thinking about 
again . 

One difficult thing for any manager or executive to do 
is any step that borders on ruthlessness, particularly with 
his own people. Few managers are capable of removing a man 
who is not doing his job. However, the project probably 
has several more years to run and. the need to have the right 
people in the job is obvious. The same features apply to 
changes in structure because this affects people. Again 
these changes may be necessary. By having parts of your 
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organization involved in the organization rolook you will 
help achieve the momentum to carry out the changes that arc 
needed. 

First, take a look at all of your interfaces. Some 
which are particularly susceptible to problems are those 
with other centers, those with primary investigators for 
on-board experiments, those with technical working groups and 
panels, those with the procurement organization, those with 
center staff, those with the center technical organization, 
those with center R & QA and Safety offices, and those with 
NASA Headquarters offices. Inside your own organization, you 
should look at the organization between line and staff ele- 
ments, at the relationship that any of your assistants have 
with other parts of the organization, at the administrative 
and personnel relations, and at any non-cooperative single 
elements. If you identify friction or problems, either 
in structure or people, they should be fixed, not lived with 
throughout the project. There is too much to do to take 
time for continuous patching. 

You should also take a look at your organization from 
the point of view of the job to be done, as opposed to whether 
problems exist. For instance, do you have a hardware office 
where the components are so far along you can combine it with 
other offices? Do you have such things as administration 
and personnel separated, where the work is now routine and 
could be combined? Do you have staff offices, such as on 
systems analysis, that could be combined or abolished? These 
anti-empire building decisions are the hallmark of a center 
executive and a source of vital spaces for other needs. 

Another separate question is the relationship of your 
line organization, your staff, and the center technical 
organization. In order to get underway have you given them 
all the same authority in some areas? Often all of these 
organizations come to feel responsible for the same total 
subsystems or disciplines. To have more than one organization 
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working on a problem is sometimes desirable. To have total over- 
lap or two or three organizations can bring about some clash, 
particularly with the contractor, and you probably cannot afford 
the luxury. An example might be where there is an R&QA staff 
function in the Center technical organization, and you have an 
R&QA staff function. Further, if you have a hardware line office 
developing a specific piece of hardware, then that office chief 
or one of his people is directing the contractor on R&QA activi- 
ties. Is it then clear what each of these activities is doing with 
reference to R&QA? Are they all talking R&QA with the contractor? 
Is each of these offices capable of initiating an action which 
can result in a change order or work authorization? If so, you 
have a little organizational arranging to do. It doesn't neces- 
sarily mean abolishing an office or keeping people out of the pro- 
ject. It simply means that you must make clear what each is to 
do, and how. 

Another area that bears checking is the amount of cen- 
tralization or decentralization that you have. There is no 
right answer to how much decentralization is enough. General 
Motors and the Ford Motor Company bear witness to how different 
approaches may be right. What you should do is examine the 
status you have and decide if it needs changing. You can note 
il all decisions seem to come to you and then decide if you 
now have subordinates who could make some of these decisions. 

Or perhaps, you have given out so much authority that prac- 
tically all decisions are made at staff or hardware office 
levels and these decisions are not showing unity of purpose. 

In either case, this is a good time to make some adjustments. 

A likely alternative is that you believe you are decentralized 
too much or too little and do not recall particularly direct- 
ing that way of working. In this case, examine your procedure 
and yourself. To get this back under control quickly is to 
be the aggressive project manager you are expected to be. 

An organizational area that really should be thought out 
at the beginning and bears checking now is the area of your 
offices which are separated from the home office. These 
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resident offices, test groups, launch groups or other 
separated groups are always potential trouble spots. Do 
they have a home office in your organization where they 
can expect support and assistance? If you are the sole 
contact for any of these offices do you make the necessary 
time available to be the contact or line of authority? Should 
you consider a different reporting arrangement or a separate 
contact for assistance? If these offices have personnel 
from other offices such as procurement, R & QA or test personnel 
from center organizations, are the authorities clearly under- 
stood? Are the duties overlapping or conflicting? Are the 
arrangements with the contractor satisfactory in areas where 
more than one organization is involved? Lastly, what is the 
arrangement between your home office and the separated offices? 
Where these offices have a total mission, is this properly 
integrated into your home organization? Where these offices 
are supporting parts of the home organization , is support 
really provided? Is the arrangement properly understood? 

Is the contact and authority from the home office through 
these offices to the contractor properly spelled out? Does 
your office visit, call, or write the contractor without keeping 
these outer offices informed? Lastly, this separation can 
feel like isolation. What steps do you take to make these 
offices feel they are a part of the home team? 

When pausing to look at organizational aspects, one 
should think of a related behavioral item-motivation. Be- 
havioral scientists have afforded more study to motivation 
than any other subject. Textbooks study motivation in con- 
junction with leadership. Managerial decisions have been 
categorized as either planning or motivational. The latter 
implies that behavioral responses must be obtained from 
organizational participants. The former simply implies that 
decisions come from responsbilities planned organizationally. 
More and more organizational and management studies are con- 
centrating on the human aspects of the job. Whether you 
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believe in the teachings of the psychologist or not, the 
human problems are getting more attention each day. Whenever 
one tries to treat the human problem, he must treat motivation. 

We do not want to get into textbook approaches too far, but 
some appeals should be noted. Pay, prestige, titles, publicity, 
and status symbols (rugs, paneling, etc.) are motivators to 
some degree and should not be overlooked. Some of this class 
of item can be slipped easily into a class called "dissatisf iers" 
meaning something that is expected, something to "gripe about" 
if its missing. Examples would be a good working environment, 
good hours, etc. All of these types of things have their place 
and should be remembered by you. However, there is a higher 
type of motivation that reaches talented and trained personnel 
of the type you have in your organization. You should give 
serious thought to how to improve this motivation. It will 
improve your project and satisfy your people. These moti- 
vators are man's desire to achieve something worthwhile, 
man s desire to use his intellectual capacity. These mean 
several things to you. You must organize and delegate care- 
fully to get the most from your people. You must create the 
proper overall environment. This is not just physical environ- 
ment but total environment. You must let people achieve 
and advance. Most of all, you must be a leader that makes 
them realize their efforts are worthwhile. You must reward 
progress with responsibility. You more than anyone, with 
encouraging words, proper rewards, your own deduction, and 
some imagination can be the major motivatinal force that 
brings your people to new heights of accomplishments. 

The last organizational subjects to check are related 
to motivation. You should observe your administrative and 
personnel office to be sure their objectives serve the Center, 
yourself and your people. It is easy for such an office 
to lose its balance. You should also watch your development 
and training programs. These cannot just happen. When a 
training course or a promotion becomes available, do not 
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let an assistant place John Doe’s name on the list. Instead 
have your office work out a plan for awarding these items 
to the most deserving. Get several people involved in these 
important decisions. These morale items or motivators must 
be handled as if they are important. They are!! 
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CHAPTER VI 


MANAGEMENT DISCIPLINES 

The remainder of this report will be devoted to discussing 
many of the problems and decisions that occur in individual 
subelements of the project. This chapter will consider manage- 
ment disciplines and Chapter VII will consider other individual 
decision areas. It is not expected that all possible sub- 
elements will be discussed for your particular project o* that 
every decision you may be confronted with will be taken up. 

It is expected that coverage of almost all areas of project 
management is included here and that the many problems and 
decisions presented represent probable areas of interest to 
you and a reasonable coverage of each subject. Careful study 
of each subject and the suggestions presented are sure to assist 
you in the areas covered and trigger your thinking in related 
areas . 
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1. Project Control 


As the first item under Management Disciplines, Project 
Control may not seem to fit the title. Is it a discipline, 
or an organizational element, or a collection of elements 
or disciplines? I start with it under disciplines because, 
accomplished properly, it is a difficult and necessary dis- 
cipline. If it is broader than that, it is just further 
enhanced. It is listed first because it is the heart or basis 
for so much of your effort. For instance, such a group may be 
the means of initiating any actions you require as a result of 
this handbook. 

For the purpose of definition, I will assume you have 
taken this discipline and made an organizational staff element 
of it. You may call it something else, but somewhere you 
need a group of specialists who take care of many things. 
Unlike test, or quality, or engineering offices whose duties 
are evident from the title, Project Control duties are only 
partly evident by the title. They do execute project control- 
type of functions such as scheduling, budgeting, etc., but 
the duties should be much broader. Somewhere you need a 
personal staff which in some cases takes care of problems 
that just do not fall clearly to other elements. In other 
instances, they take care of sudden or unexpected problems, 
or problems that cut across more than one area. 

As an example of such unstructured areas that must be 
accounted for, one could think of your suspense and action 
item system. If you think of this as purely a personal 
problem, you may have your secretary watch such items. How- 
ever, remember you have grown, you have a project now, and 
your thinking needs to grow with the project. Other people 
need to know what items are now suspense items. You should 
feel free to have action items in great abundance — from 
administrative to technical. By keeping action items assigned 
to all elements you are keeping the project viable and alert. 
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Also, you are involving many people without an intolerable 
effort on your part. It is vital that this system with suspense 
dates be kept accurately, fairly, and visibly. It requires 
the effort of some personal staff and is therefore a logical 
assignment for your Project Control Office. 

If you are now convinced you need some control and personal 
staff, called Project Control or possibly by another name, 
what assignments might it have? First, in broad areas early 
in the project, you will need help in establishing management 
philosophy, responsibility and authority, project management 
systems, management communication, organizational and contractor 
relationships, project requirements, policies, procedures, goals, 
objectives, project reviews, and of course, project control. 

In your project plan, this office may write the chapters or 
subelements on the management plan, schedule control system 
plan, procurement plan, data management plan, configuration 
management plan, facilities plan, manning plan, financial 
plan, data interchange plan, and others. The main thought 
behind the above listings is to cause you to realize that there 
are many requirements that could be assigned many ways. It 
is usually better to organize a highly qualified well-led 
office, capable of handling the unforeseen than to assign items 
to one office one time and to some other office for the next 
item. 

Of course, if you use a group called Project Control 
as suggested, one large part of their responsbility will be 
concerned with helping you with control of the project. 

Timewise, control might be thought of as occurring in five 
stages : 

1. Establishing a baseline definition, 

2. Measuring and analyzing performance, 

3. Resolving problems, 

4. Establishing and monitoring a reporting system, and 

5. Maintaining a status system such as a Management 
Information System or Control Room. 
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Although elements of control are assigned elsewhere 
(i.e., technical performance), the balancing of performance, 
cost, and schedule must be established separately. Action 
item displays, configuration management displays, schedules, 
cost status and performance require more than just display in 
depth. In fact nothing is worse than having voluminous data 
presented to you while everyone waits for your brilliant 
analysis. This data must be analyzed and digested to some 
extent before you see it. This is not to say that you should 
only see conclusions, but the alternatives you have should 
be studied. This requires a talented, well-led group, if 
the choices are to be meaningful. 

A good Project Control Office can take a lot of work 
from your shoulders. The problem resolution system, the 
various schedules, budget changes, etc., create a need for 
analysis. If your Project Control automatically analyzes 
the various problems which you must face, considerable im- 
provement in your decision making process can be expected. 

Your reviews will not just happen-properly . Thought must go 
into agendas, speakers, problems, approach, etc. Also, your 
presentations to higher management, even though the individual 
pieces come from different organizational elements, must 
be organized, redone, f ollowed-up , and analyzed. Your time 
is too valuable to get into the stream of preparation. It 
is vital that these activities be handled for you. Obviously, 
what we have discussed is vital to the project and the items 
are ones you are personally involved in. If you have to do 
the work over, little is saved. Pick your Project Control 
personnel with care. 

This discussion has treated the discipline or organi- 
zational element of Project Control as a whole. Many of the 
disciplines discussed under subsequent headings will be a 
more complete discussion of elements which you may assign 
to your Project Control organization. 
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2. Project Planning 


Any new Major Development Project of NASA's becomes sub- 
ject lo the requirements for planning and approval as provided 
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by NASA Policy Directives. Project Planning is the formal NASA 
system that prescribes agency wide policies and guidelines for 
planning approval and conduct of major development projects. 

A NASA policy stated, "It is NASA policy to undertake the 
implementation of major development projects only on the basis 
of plans and analysis that clearly define the work to be done, 
its programmatic, managerial, resources, and schedule implica- 
tions and the assurance that the required technology can be 
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made available." Project Planning is the means of implement- 
ing this policy. It requires the participation of senior NASA 
management at predetermined "decision points". Formal phased 
planning required each major NASA project be planned and carried 
out by a formal plan. The word phases as opposed to separate 
plans is emphasized. Each of the phases was preceded by an 
initiating decision by the Administrator and other senior man- 
agement. Thus, each phase should provide the information 
necessary at the end of the phase to enable management to de- 
cide on proceeding. Although NASA has departed from this rigid 
phased process, the thoughts are worth reviewing. 

Formerly, the first three phases, A, B, and C, involved 
planning and definition of the project. This included prob- 
lems, objectives, technical approaches, state-of-the-art, etc. 
Phase D was concerned with development and use of the actual 
hardware systems. Sometimes different Centers combined or 
expanded the phases. 

Since these phases are still useful in planning, to be 
more specific on the phases, Phase A is preliminary analysis 
and involves the feasibility analyses of several alternatives. 
This phase should not be ended until the overall feasibility 
can be evaluated and management can select the best approach. 
Phase A should be performed largely in-house, possibly drawing 
on Supporting Research and Technology (SRT) or contracted tasks. 
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Phase B is the definition phase, consisting of further 
investigation of hardware approaches. It involves detailed 
study, comparative analysis, conduct of Supporting Research 
and Technology and preliminary design. It should result 
in analytical reports and recommendations for finalizing the 
approach which best meets requirements. This is mostly a con- 
tracted effort with considerable in-house analysis and SRT. 
Therefore, contractor selection will be a major effort during 
Phase B. 

The actual design accomplished during Phase C should de- 
fine in detail the project approach selected. This is then de- 
tailed definition. This phase should permit a completely defini- 
tized statement of work for finalizing the hardware. It 
includes system design, breadboard work, backup system require- 
ments and any other assurance that the technical milestones 
can be met. Some Centers rebid the effort after Phase C. 

Phase D includes developing, fabricating, and testing 
a prototype. This includes all special tooling and equipment 
oriented for any production required. It also includes build- 
ing all hardware items and providing engineering, technical 
services, etc. , required for the duration of the project. 

Project Planning is the only NASA means of having a major 
development project approved. It requires preparation of a 
Project Plan in depth and a Project Approval Document. 

It is useful to review what NASA has in mind in Project 
Planning. Some of the features are: 

a. To phase the project work so it meets the project 
needs . 

b. To minimize major costs and delays by insuring that 
the technology is in hand. 

c. To maximize use of competition for both the govern- 
ment and the contractors. 

d. To insure early preparatory effort by requiring com- 
plete project definition. 

e. To emphasize the need for sound planning in depth for 
highly advanced technology systems. 
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Therefore , it can be seen that although it is not NASA’s 
intent to hold NASA managers to the rigidity of phased 
planning in four specific phases, the usefulness of what these 
phases can do for the project is still real and still in line 
with the above desired features. One should keep these steps 
in mind but shape the planning to fit the needs of the project. 
The highly structured phases insured against risk by a rigid 
process of checking technology status. This structure can in 
turn cause high costs from delays. NASA now, while still 
recognizing the need for phased and orderly plans, allows the 
manager to exercise judgment to minimize costs. NASA then 
depends on the reviews of project planning in lieu of a rigid 
process. Project Planning Methods will change but NASA’s 
objectives for planning - to control costs , be sure of technolo- 
gy, etc., won't change. You should plan with these in mind. 
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3 . 


Manning 


There is usually very little documented on the subject of 
project manning. Possibly it is not required since most pro- 
ject managers seem to be keenly aware of their need for top 
talent in large numbers. It is not the purpose of this dis- 
cussion to get you to overstaff your project. Too many people 
in the project office are as bad as too few. 

On the other hand, it seems to be a fact of life that a 
new project starts with an uncertain future and Center manage- 
ment has to carve the project resources, primarily manning, 
out of existing organizations. The uncertain start, the 
alway s-present hope for more efficiency and the difficulty of 
obtaining each space generally leads to a lesser project 
strength than was anticipated. Possibly more serious is the 
fact that your project must have superior lead personnel. No 
where is the quality of people felt more than when a project 
first starts. Your project leaders must be experienced, moti- 
vated, ahd self-starters. 

Just being aware that this perennial problem exists prob- 
ably won't solve it. What can you do? How can you solve 
the problem? The best start is to have an accurate assess- 
ment of your requirements. It is worthwhile to go over a 
checklist such as this book and mar k your project manpower 
requirements on each function where you will require effort. 

If for instance you are assigning safety to your systems 
engineering group and do not believe it will require additional 
manpower you cross out that requirement. If you have arranged 
for a Center logistics office to do the bulk of your logistics 
work you many need only one man as interface to the contractor 
or contact point, and for project assessment. With a care- 
fully prepared assessment of your needs you are in the best 
position to sit with Center management and judge which per- 
sonnel and how many personnel will be assigned to your project. 
If your needs are greater than the resources, you are then 
prepared to negotiate Center assistance in functional areas 
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where a direct assignment to your project is not accomplished. 

It is recognized that personnel needs are always greater 
than the available resources. It is also recognized that it 
is difficult to assign the full strength of a project office 
all at one time. However, the other side is that the greatest 
needs for a project office are at the beginning when everything 
is starting at once. Another problem that adds to the issue 
is that once you accept a block of people with a view to in- 
creasing the number later, you will find the increases hard to 
accomplish. The availability will never improve. You will 
have your project underway and will apparently be doing a good 
job. No one can see why your needs should increase since you 
start at the peak. In fact, if one waits a while the project 
requirements should lessen. Lastly, you will have appointed 
all managers so that late arrivals can only work at lower 
levels . 

It is for reasons like this, logical reasons, that many 
projects never get started right. So many things must be done 
to start a project right, that if these aren't done, you will 
have major difficulties later. 

Therefore, you are urged to take the following steps as 
soon as you are named to the project: 

a. Study your personnel requirements as discussed above. 

b. Understand your key personnel and your organization 
so you can apply personnel logically. 

c. Negotiate with Center Management your total personnel 
plan. If it means you cannot have everyone at the beginning, 
negotiate the assignment date of each increment. 

d. Think out and negotiate the selection of key personnel 
with care and persuasiveness. The loss of two or three key 
persons for whom you have great need can have a major effect 

on the success of your project. 

e. If possible, have an understanding of all of the 
above before you start. 
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4. Financial Accounting and Control 

So far most of the things we have talked in detail about 
have been technical in nature. Some previous subjects could 
be emphasized administratively as well as technically, i.e., 
configuration management. Let us mix in one or two pure 
management subjects, if no other reason, to show that these 
subjects range in importance as high as the technical subjects. 
Also, there is no real separation of the management world, for 
instance into the "financial” and the technical world. One 
depends on the other. 

Financial reporting is a continuous activity between 
NASA and the contractors, and through the management levels of 
NASA. It includes such things as use of work packages, trend 
analysis, contingency funds, and many disciplines. Cost accumu- 
lation and reporting must be done precisely. As we will discuss 
throughout this section, budget estimating and planning are 
most difficult processes. Excellent guidance in these areas is 
available in the NASA NHB or "Procedures for Contractor Report- 
ing of Correlated Cost and Performance Data . " ^%asic contract 
budget requirements are negotiated with the contractor based 
on Part I of the CEI specification. The contract value is 
then broken out by fiscal years, this constituting an agreement 
with the contractor on fiscal year requirements. You must also 
account for the fact that as the project progresses, you will 
have to amend the contract to include changes which must be 
authorized, negotiated, and executed. Troublesome also is 
the fact that many changes are of an urgent nature which 
necessitate authorization to the contractor to incorporate 
the change based on a preliminary budget estimate, negotiating 
later the exact value of the change. Estimated variances in 
the work in the contract, whether overruns or underruns, must 
also be contemplated. A major cause of variances is schedule 
changes, usually slippages. Such changes tend to decrease 
early fiscal year requirements while increasing later year re- 
quirements and normally result in an overall increase in runout 
costs. 
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During the preparation of your budget, contract changes 
must be anticipated and estimated for the coming year and for 
the life of the contract. Some changes can be anticipated, 
for instance additional later hardware buys, and these should 
be included in the budget. Other unanticipated changes, such 
as to correct flight anomalies, must be anticipated and esti- 
mated. These estimates require judgment based on experience 
with test programs, launch activities, mission changes, etc. 

Past programs as well as experience provide a basis for calcu- 
lating this part of the budget. All of these pieces put to- 
gether then make up your total budget. You can see it is 
difficult to estimate (we’ll comment on that again later), 
and it is even more difficult to administer. 

Once NASA and the contractor agree and a dollar amount 
is negotiated to match a schedule and CEI specification, 
planned monthly cost rates are plotted for the current fiscal 
year lor each major contract. Using inputs from the contractors 
533 reports and work breakdown structure reports and any other 
means available, you must carefully compare and analyze monthly 
expenditures against the planned monthly cost rate"^ Any ap- 
parent overrun or underrun must be considered along with all 
current activity in the budget. For instance, if a contractor 
makes an adjustment in overhead rates for the previous year, you 
might appear to have an underrun whereas actually you do not. 

You must also budget and fund many activities which are 
not a part of the prime contracts. These activities include 
in-house work, facility contracts, support contracts, trans- 
portation costs, propellant usage, DOD costs, outside fabrication, 
experiment development, special tests, etc. As you plan and 
execute these many budget activities, the contractor is managing 
his budget, too, trying hard to uncover anything new about the 
budget by any management means available. 

Having discussed the makeup of the budget, before going 
into problems and budget control, let us amplify further on 
the overall budget call and budget system. The government’s 
fiscal year budgets are formally initiated twenty months or 
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almost two calendar years earlier. The Centers initiate bud- 
gets at the same time, thus having overlapping budget activity. 
These activities are reflected in the Program Plan which is 
submitted to Headquarters as many as four times each year. 
Headquarters or the Office of Management and Budget (indirectly) 
may modify or cause modification to the POP at any time. The 
POP, or program operating plan, compares both obligations, ac- 
crued costs, and commitments with the budget plan. In Centers 
having several dozen projects and hundreds of research tasks, 
there may be one or two thousand research and development bud- 
gets prepared each year. These must be carefully planned and 
executed. Usually the Center reviews are exhaustive in this 
area, as they should be. Also, Center and Headquarters receive 
many detailed budget reports. Whereas you must make continuous 
or daily budget decisions, the Headquarters and Center approaches 
are to more detailed analysis, taken in conjunction with other 
known budgetary influences, such as changes to indirect costs. 
These analyses can be quite useful to you and since they are 
generally computerized can often go beyond your capability or 
effort available. 

In considering the overall budget, one area is worth 
mentioning separately. This is the area of cost estimating. 

Such estimating includes initial project estimates, the inde- 
pendent estimates of higher authority, the estimates in sup- 
port of change requests, and also those used with cost ef- 
fectiveness studies. This is such an important area it deserves 
special thought and possibly some sophistication. Of course, 
no estimating is good without your project engineers or systems 
engineers being directly involved. They know the project, the 
hardware, the extent of changes, etc. However, costing and 
estimating is a science and an art. It requires people with 
experience and with some skill. It requires use of ever ad- 
vancing techniques. It is not easy to combine these features. 
Engineers and budget experts are not easily combined. If the 
budget experts belong to the Center or one of your staff 
offices separated from the line functions, the problem is 
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compounded. I i the budgets are all prepared at your level 
and the experts are on your staff there should be no problem. 

If the budgets are prepared at a lower hardware level, and the 
experts are at a higher level, you must be careful not to usurp 
the prerogatives of the responsible level. You must find ways 
around it, such as loaning the experts to the responsible 
level. Lastly, estimating is more than skill, particularly 
when first estimating a proposed new project or a change you 
want to make. To suggest that anyone deliberately underesti- 
mates a cost would be a severe charge. This probably does not 
occur. On the other hand, for Government agencies to continu- 
ally misestimate costs, nearly always on the low side, gives 
rise to questions. That does occur. Are our estimating 
techniques this poor? No. The problem generally is enthusiasm. 
With a strong desire to do a project that high costs would 
kill, we become optimistic that we, for the first time, can 
make every crossroad turn out favorably. We think we have 
better people, better techniques, better management, better 
contractors and are suddenly going to do it differently. A 
word of caution. It is good to have a challenging project 
and a Project Manager should be optimistic, but if optimism 
surpasses judgment, be careful. You are judged on balancing 
performance, costs and schedules. The problem of schedule 
generally turns into a problem of cost. Managers today will 
probably succeed on technical performance, but are likely to 
fail on costs. When you discuss embarking on a new project 
at the bottom cost estimate, think about it. 

Once a project starts, a project approval document or PAD 
is written. This is signed at the Administrators level and is 
a contract from that level outlining resources, dollars and 
manpower which NASA assigns to accomplish a project. It also 
assigns Center responsibility and is thus required before a 
project can begin. The POP cycle then is the Centers request 
for the funds to execute the approved project. You will be 
concerned with the R&D budget and the construction 0 f facili- 
ties budget which are separate. Your project will be line 
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items in these two types of appropriations and as such is 
finally approved by Congress. Everyone today is concerned 
with expenditures. You have an obligation alter your budget 
is formulated to set up the kind of controls that cause you to 
meet your commitment. 

Because there is no one cost system known today that can 

solve the contractor’s and NASA's problems, it is the general 

policy not to specify a particular system for implementation 

by the contractor. The RFP usually specifies some general 

requirements, some reporting requirements, and has provisions 

for fee enhancement for a well-managed project. One of the 

recent standard provisions is that the contractor's system 

be based on the work breakdown structure. In such a difficult 

areas as cost, remember the profit motive (fee, expanding 

base of corporation, paying the overhead of a particular plant, 

etc.) is the basis of the contractor’s activities, you probably 

cannot spell out the details any more closely in the RFP than 

is done now. However, the fact that you are unable to specify 

a precise cost control system and the fact that some leeway 

is left to the contractor is the beginning of the difficulties 

you will have with cost control. For this reason, more than 

in any other area, you should not rely on any one system. You 

16 

need checks and cross checks. You should use the 533 data. 

It is fairly good, but not as a cost report standing alone. 

You should use the cost portions of your management informa- 
tion system. These are improving. They not only cost each 
discrete package so that you can investigate exactly where 
the problem is, the ability to plot the planned value of the 
work scheduled against the actual value of the work accomplished 
also assists your analysis. You should also check your manage- 
ment cost reviews against known problems to see that you are 
getting to the bottom of current issues. Reviews are very use- 
ful if you don't allow them to become stereotyped. Very 
little is learned from a general cost presentation by the 
contractor since it covers so much area. Your staff should be 
able to provide areas to penetrate where recent problems have 
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occurred, where schedules have slipped, where tests have 
been held up, where manpower has been added, where materials 
have been scrapped and so on. Cost reviews can be deadly 
boring or extremely active. You should also use any other 
cost control method that is required or that serves a distinct 
purpose. In costing it is usually the cross checking of 
different approaches that will really afford you an understanding. 
If costs get out of hand, you should not hesitate to take a 
combined technical, schedule and cost team to the contractor's 
plant and go through the projects costs in depth. 

Since cost accounting is difficult, you should do all you 
can to make the road easier to travel. Negotiations in depth, 
closely followed by you and your offices, will go far in 
insuring that you and your contractor have the same understanding 
of project costs. Also, even though you do not specifically want 
to specify the contractors financial and control systems, you 
can state some of the properties his system should possess, 
such as: 

a. Be based on a specified work breakdown structure. 

b. Have a capability to permit the measurement of the 
planned value of work accomplished and resources consumed to 
date and to compare the planned values with actual costs so 
that a variance can be established. 

c. Can extract data from the system which permits analy- 
sis of the planned value of work accomplished to date, and 
actual costs to date for hardware items in terms of cost ele- 
ments such as direct labor hours, dollars, material dollars, 
overhead, etc. 

d. Have a capability of summarization and reporting 
of planned, actual and forecasted cost and schedule status 
so as to achieve data from the lowest levels of the work 
breakdown structure up to and including the total contract cost. 

One of the earliest information systems was PERT/Cost. 

After advancement of the computer and the work breakdown 
structure, many Centers advanced the state of the art on these 
latter systems and have developed very usable approaches to 
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cost control. Other Centers have retained PERT and have 
combined it with the work breakdown structure. The PERT 
fragnets with their schedule arrangements are ideally suited 
to combination with the WBS. As stated previously, any combi- 
nation of systems will work if you take an interest in it, 
use it and manage it. 

As you know, the budget area is one of the most difficult 
of all for the engineer to work. It is difficult for you to 
understand and work with your own budget group. It is diffi- 
cult for the Center engineering offices to develop an appreci- 
ation for budget problems. It is the area where it is most 
difficult to work with your own budget. It is the stumbling 
block for everyone for accomplishing technical performance. You 
must listen to their methods since you need all approaches. You 
must establish a working relationship with your contractor. 

This doesn't mean you want to establish a cozy relationship 
on cost. It means you must understand how you are working 
with the contractor. Can verbal commitments be understood 
and relied on until covered in writing? (It is agreed that 
verbal commitments should be avoided ordinarily.) Do you have 
a game going where each tries to outguess and outplay the 
other? This is not recommended since your assets are not 
sufficient and the stakes are too high. You must develop an 
honest relationship with the contractor. 

It is suggested that once your cost plan has been imple- 
mented, you give it enough attention to set a proper pattern. 

Ask your staff for ideas on how to control costs. Implement the 
better suggestions and let the contractor know of the importance 
you place on costs. After an initial cost problem, schedule a 
special meeting with your contractor and ask for his reviews 
and approaches. Schedule a thorough premeeting with your 
staff, and possibly with Center and Headquarters personnel. 

Go over the problem. Determine if it could have been avoided. 
Determine if there are solutions to the problem. Prepare 
questions for use at the contractor meeting. At the meeting, 
penetrate the problem with probing questions. After the 
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meeting, have a small meeting with top contractor personnel. 

II you are satisfied with the general meeting, say so, and 
let it be known you will probe cost problems as necessary. If 
you do not think the problem should have occurred, tell the 
contractor how it could have been avoided. If you think it can 
now be corrected better than was presented, say so and tell him 
how. More important, let it be known you are interested in see- 
ing the results of what has been agreed to. You want to under- 
stand now how good commitments are. Go over the commitments 
again and set a time to check on results. Insist he not hide 
anticipated or recent cost problems from you while he is working 
on a solution to present. 



5. Project Scheduling 


After a discussion on budget management and management 
information systems , there is less to say about scheduling. Bud- 
get and schedule go hand in hand and the basis of MIS is to tie 
the two together. The most critical time in scheduling is before 
the project starts. Two initial facts affect schedules; every- 
one wants the developed project as soon as possible, and the 
longer a project is stretched out, the more it will cost . 

These facts cause an optimism in "selling" a project. In fact, 
it seems at times that unless you are very optimistic you can’t 
get a project started. This causes problems. After the pro- 
ject is started, if it can’t stay on schedule there is only one 
reason. You did not manage the project properly. Also, there is 
nothing worse in the eyes of Center and Headquarter management 
than for the Project Manager to realize his schedule is too 
tight and to announce, right after the project has started , that 
the schedule is too tight and thus he needs more money. Today's 
environment complicates your problem also. When Apollo was 
started, the Administrator was able to announce that to accomplish 
the mission in the decade would cost 20 to 40 billion. Success 
is probable under these circumstances. When Manned Space Flight 
started the Shuttle, a project of comparable complexity, every 
ounce of schedule and budget was squeezed from the project, 
making it difficult to achieve. However, you must not want 
your project so badly that you accept it under nonrealistic 
terms . 

Once you have a realistic overall schedule, you need to 
develop a project schedule plan. It is not sufficient for a 
major project to just use the schedule information that falls 
out of MIS. You need a schedule plan. Some features of the 
plan should be that everyone is using the same scheduling and 
reporting format. You should then take the major schedule 
events listed in the PAD and POP and expand these into many 
major milestones affecting all parts of the hardware program, 
the R&QA program, and so on. Then lower level schedules are 



built to the same format and based on the same control mile- 
stones. It is suggested that on each lower level schedule you 
list a person, right on the schedule, responsible to you for 
that schedule. This will usually be a key person in the disci- 
pline or hardware involved. Such a system will assist you in 
quickly knowing of problems coming from the bottom up in that 
particularly lower level schedule. It will help the person 
shown plan for schedule changes coming from the top down in 
his area. The overall system permits evaluation, analysis 
and monitoring of the project. To make sure your scheduling 
information is accurate and timely you may need more than one 
concurrent system feeding a single format. You use an MIS, 
control room display, PERT, Schedule Analysis and Review Pro- 
cedure (SARP) and others. When PERT data is used for schedul- 
ing major projects, it is usually converted to bar graph form. 

A good technique for displaying schedule information to upper 
management is the Schedule Outlook Trend Charts. These can 
be useful to you, too. They help detect difficulties in early 
milestones affecting the one date they usually cover, first 
launch. Trend charts are useful to you also in noting a con- 
tinuous trend to slippages in one of your level schedules. If 
you have a slippage and a plausible reason for it, but are 
also showing continuous slippages you have a problem. You will 
find it takes a major effort to turn around a continuous slip- 
page, more than correcting a problem for each event. 

As in budgets you must have a suitable working relationship 
with your own offices and with your contractor. Your superiors 
should be able to expect the same from you. As in budgets, 
there is a tendency from a proud office to fix a problem before 
talking about it. Your contractor may plan to work around the 
clock in order to make up a ’’blown 1 ’ test schedule and then in- 
form you he has had a little problem which he has fixed. This 
must not be tolerated. All such events do not "fix” easily and 
may drag on. You may be counting on the schedule in question. 
Worse still it is a break in the discipline of the system. If 
you can use this method here, why not use it on late deliveries, 
etc.? Instead of depending on a telephone call between the 
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proper people lor small problems, use a system of flash re- 
ports, say between project control offices. 

For your routine schedule activity, you should watch 
closely for any signs of a schedule problem having different 
indications from different sources, (you will want to know 
why one system didn't work) a cost problem developing, technical 
problems, test difficulties, etc. When some such a sign is 
truly indicated, you will want to pursue the schedule concerned 
with all resources. Visits to the contractor, premeetings 
with your own staff, management meetings with the contractor^, 
etc., as in budget, are in order. 

A difficult management problem with schedules is that 
almost any scheduling problem can be solved by a change order 
adding cost to the project. You are sure to be offered this 
solution as soon as a scheduling problem appears. There are 
times when this solution will be necessary. On the other hand, 
if a scheduling problem is solved with additional funds when 
this solution is really not required or when one doesn't take 
time to establish responsibility for these funds, a precedent 
will have been set. This is particularly noteworthy when more 
than one organization is involved in the interface where the 
scheduling problem occurred. It is necessary to settle the 
scheduling relationships at an early date. Too often in the 
haste of solving a scheduling issue, the necessary visits to 
the contractor plant and the necessary contracting steps are 
slighted in order to stay on schedule. Early in the project 
it is unlikely that a missed milestone will affect end dates. 

It is better to stop right then, report a missed schedule to 
higher management, and take time to solve the problem properly. 
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6. Configuration Management 


Configuration Management was ushered into NASA in the 

1960 T s when it became apparent that projects were becoming 

so big and complex that the original baseline and subsequent 

changes were impossible to track without assistance. To 

get underway, NASA borrowed the term and the system from the 

Air Force. In the Air Force, configuration management is 

19 

described in USAF appropriate documentation. In NASA, the 
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adaptation is described by the suitable NASA NHB document. 

Almost all Centers handling large projects prescribe that 
configuration management will be used on these projects. It 
is too expensive in the long run to do without it. However, 
because it is also expensive to use, each such Center has 
published policy covering its implementation at that Center. 

In these policy documents, you can find a number of references 
which permit you to go deep into the subject. 

Configuration Management is primarily concerned with 
three types as activities: configuration identification, 

configuration control, and configuration accounting. Some- 
times systematic technical evaluation and approval of changes 
of hardware items to the black box level, with software probably 
to the subroutine level, are also a part of the process. 

Center policy and instructions include such items as require- 
ments for Configuration Control Boards (CCB) , requirements for con- 
figuration baseline dates, and requirements for submitting 
changes to higher authority. 

The system is a necessity, but you must decide the depth 
you wish to have in your projects. You should ask your con- 
figuration management group to give you the options you have 
in implementing the system with rough price estimates for 
each. Identification and control will not have as much range 
in their options as accounting. Accounting is also one of 
the more expensive portions in the system. 
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You will need certain project documentation in order 
to implement the system for your project. Some of the 
documentation requirements may be alleviated by Center 
policy. One way or another you need such things as: 

a . A project configuration management plan, 

b - A configuration procedural manual to instruct 
all project personnel, 

c . A minimum requirements document for each project 

contract. These must be contractually implemented. 

The above special documents are in addition to a 
number of standard documents used in implementing the system. 

You must of course name an office which is responsible 
for configuration management. Any hardware offices you have 
will be involved in implementing and operating the system with 
the contractors. In addition you need a single staff office 
responsible for configuration planning, documentation, pro- 
cedures, and to act as secretary for the configuration control 
board at your level (probably level II). Technical personnel 
will be highly involved with changes, with specifications, 
with interfaces, and with baseline reviews. 

The control boards operate at several levels. In a 
large project usually level I is in NASA Headquarters; 
level II is at your level; level III is for the hardware 
managers in your office; level IV is for your resident managers 
at the contractor site (usually restricted to spec deter- 
mination, use or scrap decisions, etc.) and level V is the 
contractor’s board. Complex rules have been written to govern 
the authority of each board, but roughly the procedure is 
that a board can make decisions within its own authority, 
so long as it does not violate the cost, schedule, or 
technical authority of the next higher level. For more 
typically sized projects, one or two change board levels of 
the government and contractor are usually sufficient. 

The decisions made by the change boards are the most 
challenging ones in the project. For that matter, they are 
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the most exciting, awarding, and interesting ones you will 
probably have. For this reason, it is easy for a technically 
oriented manager to get wrapped up in the technical problems 
at the expense of other management issues. Because con- 
figuration management requires so many decisions, it is often 
listed under the project management decision process. It 
involves decisions in the three areas of project balance — 
cost, schedules and technical excellence. It is one of the 
most formal decision processes you have. It prescribes 
certain features of the decision making process which are worth 
noting. It presents decisions which must be made. It docu- 
ments the decisions so that everyone has the same understanding. 
It has a formal notification pattern which results in thorough 
coordination. Lastly, at your level, it makes it clear that 
the decision is yours and yours alone, not a voting process. 

In order for you to fully understand the process, a word 
should be said here concerning each configuration activity 
and what it is for. 

a- Identification is the technical documentation 
(specifications, drawings, test data, etc.) defining the 
approved configuration. Without this baseline, control of 
your contract, award, or penalty on contract fees, and the 
understanding of your project financial plan would be im- 
possible. 

b. Control is the systematic evaluation, coordination, 
and approval or disapproval of proposed changes to the base- 
line. The system is complete enough to let you know that 
all proposed changes are properly considered and that you 
see the ones you should see. 

c. Accounting is the reporting and documentation of 
changes made to systems and equipment subsequent to estab- 
lishment of the baseline configuration. The procedures, 
requirements, and responsibilities must all be spelled out. 

These records are of course necessary. A more pertinent 
question might be: How fast must you be able to call up 
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status? How much must your timing and format be like your 
contractor's? These questions lead to whether you computerize 
the system, etc. These factors set the costs. 

Configuration management identifies the baseline design 
and all of the engineering change proposals identified and/or 
approved which can change the baseline. This identification 
includes part I of the specification which is the requirement 
portion to include such requirements as testing. It also 
includes part II which is the design portion of the speci- 
fication. The control portions thus allow you a fairly 
complete analysis of the impact for any engineering change 
described by the engineering change proposal. You should 
always have this impact presented at the change control board 
meeting. This lets everyone hear the stated impact and it 
also sometimes brings out impacts not otherwise uncovered. 

The accounting or recording gives you the complete status of 
configuration items to varying depths and with varying 
availability. It also covers spares, contract status, and 
modification status. These pieces of information are vital 
in judging approvals and in administering the contract. 

In some instances components of a configuration item are 
considered critical from a design or logistic point of view. 
This, then, requires a detailed specification to provide the 
visibility needed at this lower level and gives you special 
control over such critical components. You should have an 
initial identification of critical items accomplished when 
the specification is written. 

Typical contractor implementation of the above require- 
ments might read something like this. "The contractor shall 
provide a configuration management system which will define 
configuration of hardware and software at any point in time 
throughout the performance of the program. The system is 
required to provide for identification of configuration 
baseline, the control of changes to these baselines, the 
maintenance of current accountability, of the status of these 
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baselines, and a progressive verification that the ’as built' 
configuration agrees with the current configuration baseline 
or that the differences are identified. The configuration 
management system will also maintain a cost-per-flight and 
schedule impact evaluation. Inherent in these activities is 
the identification of all management and technical interfaces.” 
After such an introduction, details are provided on visibility, 
detail, meetings, logistic details, GSE, etc. 
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7. Change Control 


In discussing configuration management previously, we 
discussed the system configuration that must be controlled 
to a baseline. There is really more to this process, however, 
than structure. Here, we will attempt to get at the thinking 
and philosophy concerned in making changes. This must be a 
disciplined process. It affects how you work with a contractor ; 
more important, how you work with a contractor will probably 
affect your change control. When you participate closely in 
contractor activities, you are subject to being a part of any 
changes. If you cannot hold him responsible for changes to 
the baseline, the program will be extremely expensive. A 
quote from Air Force Policy under the Total Package Procurement 
Concept brings this out, "Acceptance of Part II of the speci- 
fication is recognition that this is the product configuration 
baseline for engineering change proposals control procedures. 
Final acceptance of the item is not made until satisfactory 
demonstration and proof that the item has met all of the 
specification requirements. In summary, participation by the 
Air Force in any of the actions under configuration management 
cognizance are to be of such a nature as not to negate the con- 
tractors responsibility for any correction of deficiencies 

because the Air Force had been a party to decisions or actions 
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having an influence on such a deficiency." 

There are two sides to the government approval of engineer- 
ing change proposals, and, as a representative of the govern- 
ment, the place where you draw the line between these two 
forces is very important. It is suggested that you meet with 
the contractor at an early date and state your position as 
follows. You will suoport the approval of changes to the oro- 
ject baseline when the changes are clearly required. If the 
changes are government initiated and clearly outside of the 
specifications, thus adding work for the sole benefit of the 
government, you will support an increased fee and a modification 
to the contract. (You must recognize in making such changes 
the job may turn out to require more effort than estimated; 
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hence, have more cost even if the contract is of the type to 
cause the fee to remain fixed.) However, you should make it 
evident that changes within scope of the Statement of Work 
which are required to achieve specified levels of performance, 
must be made by the contractor in response to (contractual) 
technical direction. Some contracts do not have a technical 
direction clause with an increase in fee. This statement does 
not preclude the contractor from charging legitimate costs 
under a cost-type contract. On the other hand, if the contractual 
specification must be changed, a contractual modification (includ- 
ing a change order) will be issued for the potentially fee- 
bearing work. 

Technical excellence is a goal of most innovative engi- 
neers. Most of the engineers in each discipline, be they con- 
tractor or government, can soon find a way to do something 
better, or can achieve a line of reasoning of why something may 
not work under certain conditions. It may not; it may have to 
be. changed; it may not have to be changed. Quite innocently, 
you may find yourself developing new parts for the next pro- 
ject to be approved. As chairman of the level II board and 
the person so le ly responsible for its decisions, you will set 
the pattern lor this board and all change boards at a lower 
level . 

You cannot be an expert in every field. As chairman of 
the change board, you will have experts present for each change 
whose knowledge will exceed yours on individual subjects. You 
may hear that a component failed under a certain vibration 
level and thus must be changed. It is a flat statement, given 
by experts and may cause you to hastily approve the item. You 
should not. You should develop a procedure for change meetings 
and a confidence in your ability as a project level systems 
engineer. Assuming your own engineering organization is respon- 
sible for handling configuration management and that an 
individual is responsible for overseeing each change presented, 
you can have a very simple premeeting, just you and that in- 
dividual if necessary. He should have ideas and convictions 
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on the change that you should hear. Also, he represents a 
good place to sound out your own questions on the change. If 
he can’t answer your questions, he has not prepared the change 
properly for presentation. This two-way discussion will lead 
you to other lines of reasoning. 

It is then in the change board itself that you ’’earn your 
pay." You should develop a line of questioning that goes to 
the heart of the change. Some suggestions may help. In the 
first place, never accept first answers in any area but probe 
deeper. Ask what the requirements are that the part is supposed 
to fulfill. Is this a book requirement or a proven requirement? 
What is the tolerance this provides over and above the flight 
condition? Is this much tolerance needed? What caused the 
failure? How do you know that was the cause? How do you know 
it wasn’t fatigue? Could you have had a defective part? Etc.? 

A feature that will help with this type of in-depth probing is 
for you to assume an air of the uninformed who doesn't really 
know much about the component. In the process of getting 
you informed, you will be surprised at the number of relevant 
things that are not known by any one expert there, even by all 
the experts together. Once your probing has uncovered a clear 
reason why an "obvious" change should not be made, your confi- 
dence will grow; you will then have the respect of the board 
which will promote some future caution; and all of the lower 
boards will function more carefully before sending items up 
for approval. 

Changes that need to be made often lead to new problems, 
new failures, higher costs and delays. Changes that do not 
have to be made should not be allowed to expose you to these 
hazards. As a responsible government executive, you should 
not approve a single change that is not required. However, 
keep in mind that if the change is necessary, for the project 
to succeed, it must be made. Separating the two requires the 
keenest action on your part. You should be able to probe until 
everyone is convinced. 
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In preparing yourself lor these reviews, stop and realize 
the preparation that has occurred to bring a certain position 
to you. One or more lower board levels have already treated 
the change. A recognized fact is the acceptance of the profit 
motive in industry. The outcome of these boards affect that 
motive. You know then that the contractor treats changes 
carefully. Typically, a contractor change board meets three 
times a week and is attended by the contractor project director, 
and top staff. In a program like Apollo, one of the prime 
contracts might treat more than 2000 changes of all types 
during the program life. Usually contractor-initiated changes 
are sent to a change analysis board before going to a change 
board. This board also helps determine if the solution requires 
iormal contract change and hence, a change order. Also a 
senior management action board meets for large projects. Among 
other things, it reviews contractor change board actions. 

Also related is the fact most contractors have a senior financial 
management review. By the time you see a proposed change, it 
has acquired considerable momentum toward approval. In spite of 
this, some Project Managers turn down half of the proposed 
changes and are correct in their decisions. 

One question you should always ask in a change board is 
What other areas are affected?” In spite of your training 
your office to pinpoint these other areas, more often than not 
later changes will be brought about that were not anticipated 
when the change was made. It is rare that you can make a major 
hardware change without affecting other areas. 

A further comment on making changes is a caution concerning 
interfaces. If other level II boards operate on your project, 
any changes you make which affect that board's activities must 
be coordinated with that board. If you are treating a change 
proposed to you by a level m board, be sure no other level III 
boards are affected, or coordinate the change. 
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8. Interface Control 


Like many other project management subjects interface con- 
trol is greatly involved with many other subjects we are dis- 
cussing, but it is also worthy of separate discussion. One 
type of interface discussion is organizational in nature. Here 
we will slant the discussion more to technical interfaces; al- 
though this immediately involves the organizational divisions 
also. The interfaces in a project are probably the most trouble 
some of all the project technical areas. In the first place, 
each project of large size has an astounding number of inter- 
faces. If you have carefully assigned responsibility for all 
subsystem disciplines of each major hardware end item to some 
individual you have made a good start. For each hardware system 
then you may have subsystem managers for such things as struc- 
tures, propulsion, electrical, instrumentation, flight control, 
guidance, environmental control, GSE and possibly several others 
You probably also have individual managers for special disci- 
plines too, such as testing, R&QA, systems engineering, flight 
operations, etc. These can give you a feeling for the many 
interfaces . 

To treat interfaces quite formally there are a number of 
things you can do. First, you can divide them by category. 

The level where your project is assigned in the Center may have 
an associated project at the same level, say where another 
Center has part of the project such as the launch vehicle, 
and you have the space project. These are usually recognizable 
by the fact that more than one level II configuration control 
board is operating. These are sometimes designated category A 
interfaces. Next, are the interfaces within your project among 
various hardware end items. For instance, you may have a 
propulsive kick stage and an instrument stage. These inter- 
faces may be designated as category B interfaces. Although a 
formal designation seldom exists below these two levels, your 
major hardware managers have interfaces of a similar pattern. 

The next thing you can do after designation is write 
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formal ICD's (interface control documents) for every category 
A&B interface you can identify. The number may surprise you. 
There possibly will be hundreds depending on the project. The 
time it takes to identify and formalize all interfaces will 
surprise you, too. New interfaces are discovered for some time 
after the search is started. The formal ICD's are complete 
descriptions of the interface and also spell out responsibility 
on both sides. 

The next thing possible is to bring all of these ICD's 
under configuration management control. This will place this 
troublesome area under formal control. It will ensure that 
any change treated on one side of the interface is also con- 
sidered on the other side. For a large project this formal 
approach is necessary. 

If the project is large and the interfaces particularly 
difficult you can do more. You can establish task forces just 
to work these problems. For category A interfaces these task 
forces are usually called interface panels or intercenter 
panels. For the category B they are often called working 
groups or Center working groups. Both are discipline oriented 
and typical headings are safety, electrical, instrumentation 
communications, flight mechanics, flight evaluation, mechanical, 
launch operations, flight operations, etc. You can see that 
these disciplines cut across the various interfaces and, hence, 
test the interface for sufficiency. The duties of these panels 
and working groups could be to: 

a. Initiate actions regarding design, analysis, study, 
test, and operations. 

b. Identify and generate ICD's within project require- 
ments. 

c. Recommend solutions to problems outside the panel 
or working group. 

One other advantage of formally organizing the interface 
area, using such devices as panels and working groups, is that 
you get additional people working on your project and you often 
improve working relationships of many involved organizations. 
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It is useful for you to test the working of your inter- 
faces as often as you can. Are problems showing up at the 
contractor’s plant that your organization does not detect, 
or vice versa? Have problems occurred that are not corrected 
across the interface? Once you make everyone conscious of the 
ICD’s and the interface problem, your organization will work 
the problem better. 
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9. Systems Engineering (SE) 


A great deal of stress has been given in recent years to 
systems management or systems engineering or systems theory. 
These approaches can mean different things. In some schools 
of thought they are only terms related to computer approaches 
and engineering modeling. Here we will think of a system as 
a sum of parts to some complex - in this case, your project, 
and systems engineering as a means of tying it all together. 
It's the big picture. It's making everything work and work 
together. Systems Engineering is simply a comprehensive way 
of thinking. You might ask, if it is all of that, why didn't 
we take it up first. Perhaps, we should have. By starting 
with some other complex items, having uncertain interfaces, 
some appreciation for SE is gained, however. 

How do you separate a subject like systems engineering 
from all the other project activities? In a sense, it can't 
be separated. It includes many things. The work breakdown 
structure is a form of systems engineering - so is your 
management information system, or your development plan, the 
configuration management system, or the organization itself, 
or the final systems test, or mission planning. What systems 
engineering requires is that you set someone aside, an engi- 
neer with a staff of good engineers, to use all of the above 
things and many other pieces and put it all together. How 
do you pick the man for this job? A NASA Associate Adminis- 
trator once said that the average Center doesn't have over 
two or three systems engineers. He may be right, but we are 
back to definitions and in some pure sense there are a few. 

What we are seeking is a good engineer with mechanical, 
electrical, flight mechanics and mission understanding who 
can see the whole problem. The average person gets lost in 
the many troublesome pieces and loses his perspective. Lastly, 
he has drive. This is a lot to ask. You pick the best you 
have, (after some thought it may be a talented less senior 
man) and you give him all the help you can. 
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Your systems engineering organization must start at the 
beginning - back with concepts and trade offs. They must be 
deeply involved in the work statement, the project plan, and 
most subsequent activities. They are one of the organizational 
discipline groups, and they are your engineering staff. A 
truly outstanding and gifted systems engineering group is hard 
to find, but to some extent such a group can be trained. It 
is a place for the advancing, thinking, innovating young 
engineer . 

The project requirements definition process relies heavily 
on an effective systems engineering process for the develop- 
ment of achievable technical concepts. In concert with the ob- 
jectives of the project as expressed in the project plan, the 
objectives of your systems organization might be to prescribe 
the structure and implement a process which will: 

a. Identify, organize, and establish all necessary systems 
engineering requirements to define and control the total project. 

b. Identify and establish technical documentation require- 
ments, in conjunction with the data management group, for the 
total project. 

c. Establish an effective everyday management control 
process . 

d. Continuously execute the systems integration function 
in an organized and effective manner. 

e. Continuously provide overall systems assessment of 
proposed changes or mission alterations. 

f. Analyze concepts and trade offs on a continuing basis. 

The systems engineering process will provide you with 

essential data in the following areas: 

a. Analysis, to include: expected performance, recommended 

problem solution, mission planning effects, operations analysis, 
cost effectiveness studies, logistic analyses, maintenance 
analyses, and potential systems performance analyses. 

b. Requirements and integration constraints such as: 
structures, propulsion, ground support equipment, flight 
control, guidance and navigation, instrumentation and 
communications . 
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Systems engineering and systems analysis techniques 
should be used to insure that the project and all of its 
components, including GSE, are of the optimum configura- 
tion. This is accomplished by conducting a systematic 
analysis of prelaunch, launch and flight operations and 
determining the function that each system element must per- 
form. The element is then evaluated for its capability to 
perform the functions, which provides a means for selecting 
between component designs and for detecting design deficiencies 
The analysis is also used to insure that the various systems 
components are compatible with each other and with the launch 
site. This analysis will continue after the configuration is 
selected. Design and development testing problems will re- 
quire that continuous trade offs be made. 

Since systems engineering is one of the hard-to-understand 
areas one might read the above and say, "I still don’t know 
what my systems office is supposed to do exactly.” To give a 
closer feel of the subject for those who desire it, the re- 
mainder of this section will be comprised of a more detailed 
approach to systems management and systems engineering. There 
is more than one approach to this subject, but this one view 
may let you decide how you want your systems group to approach 
it. 

The process of systems engineering should be looked at as 
a tool for designing the project on a total basis so that 
design will reflect considerations of requirements for equip- 
ment, facilities, technical orders, and personnel in an inte- 
grated fashion. It serves as this tool by systematically pro- 
ducing systens engineering documentation which provides the 
source of the development of specifications and the backup data 
required to define, contract, design, develop, produce, install 
checkout, and test the system. 

To achieve this the systems engineering process is started 
by identifying system requirements in basic functional terms. 
These functions and associated criteria are then analyzed and 
translated into design requirements. These requirements are 
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for everything to include design constraints that have a 
bearing on the functions being analyzed. System and design 
engineering studies arc performed concurrently to: 

a. Determine the selection of alternate functions and 
functions sequence. 

b. Determine the requirements for design imposed by 
the functions. 

c. Select the best design approach for integrating the 
design requirements into end items. Utilizing the design 
approach determined from these studies, design requirements 
are integrated into end items. 

The systems engineering management documentation provides 
many of the elements for the other project management activities. 
For example, the identification and definition of end items 
provide the source for the specification tree, for cost/schedule 
planning, for control work, for the work breakdown structure 
used in procurement action, and for the basis of test planning. 
The systems engineering process does not make decisions itself, 
but it does provide a basis for the decisions and provides a 
discipline for engineering across the various contractors and 
across the end items. This discipline is achieved through the 
systems engineering plan and control, through project directive 
or, through contract instruments. The cycle is completed by 
reviews and documentation. 

The systems engineering process is an integrated process 
which specifies the hardware, computer programs, facilities, 
personnel, training and procedural data required to meet system 
mission objectives. The basic concept of the systems engineering 
process is to force a logical, systematic, comprehensive con- 
sideration of all aspects of the system requirements during its 
early design, development and test phase. Systems engineering 
encompasses the early identification of systems objectives, the 
"design to" requirements necessary to meet these objectives, 
the "build to" requirements which prescribe the ultimate con- 
figuration of the system to be delivered and the requirements 
for training, personnel, for procedural data, and for logistic 
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support. As such, systems engineering is essentially concerned 
with deriving a coherent total system to achieve stated mission 
objectives. The cycle of the systems engineering office activi- 
ties might consist ol’: 

a. Functional analysis. 

b. Functional requirements allocation. 

c. Systems synthesis. 

d. Requirements integration. 

Functional analysis is the translation of mission require- 
ments into operations, maintenance, test, and activation func- 
tions which must be performed by the various systems elements, 
i.e., hardware, computer programs, facilities, personnel, and 
procedural data. The next item, functional requirements alloca- 
tion consists of analyzing and translating the developed functions 
into requirements for designs, facilities, etc., and to list all 
known constraints. The third, systems synthesis, involves the 
performance of system/design engineering studies to analyze all 
known requirements and constraints, to create alternate design 
solutions which can satisfy the performance and functional re- 
quirements, to evaluate alternate design solutions, and to 
select the optimum approach. The final step, requirements inte- 
gration, integrates the system element requirements developed 
in the preceding steps, into CEI's, skills, training courses, 
and procedural publications. It is important to note that 
this systems process is an iterative one within the various 
functions required to design the system. 

By control, through documentation and review, all perti- 
nent details of an end item design can be traced back to a 
system requirement. The fundamental systems engineering docu- 
ments that are delivered to you are the systems specification 
and the CEI specification. Other supporting documentation cover- 
ing functional, design, maintenance and support analysis, trade 
studies, and systems effectiveness are only required on a 
selective basis. "In process" reviews are used to the fullest 
extent possible to minimize requirement for formal published 
reports. 
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If you desire to go into any of these areas further there 
is considerable data published within NASA on systems engi- 
neering. However, the most voluminous and most detailed data 
on the subject can be found in the Air Force publications. 

These are referenced in the Air Force Management Policy 

22 

documents . 

It may be interesting to note that the "Shuttle'' state- 
ment of work divided the systems engineering task into two 
parts : 

a. Systems management, to include performance manage- 
ment, configuration management, information management, 
logistic management, Government Furnished Equipment (GFE) 
management, and procurement management. 

b. Systems integration to include data requirements, 
analysis requirements, general systems requirements, mission 
requirements, and Shuttle vehicle analysis. 

This is a sound systems approach for the contractor. 

The NASA offices would have certain systems responsibilities 
in addition to those contracted. 
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10. Software 


Software is a complex technical subdivision. Everyone 
knows what it is and that it is important. Almost everyone 
knows that software has a long lead time, that it is probably 
used in both countdown and in flight modes, and that its con- 
figuration must be controlled like hardware. In spite of this, 
there appears to be only a few places in NASA where there is 
total software accountability. A recent search of management 
documents, Project Plans and Requests for Proposals found 
software listed only two times. This is not meant to imply 
that software is overlooked the remaining times. Experienced 
managers no doubt pick it up under configuration management 
or other headings. It does say, however, that if you are re- 
lying on past documentation you may miss the significance of 
this subarea. Software is expensive and critical to each pro- 
ject. It is associated with portions of the overall project 
which must be developed late in the program. It can easily 
be a time and cost bottleneck. 

The above obviously says you should initiate software 
development early. Not only that, you should baseline it 
early and place it under configuration control. If your soft- 
ware change traffic could be heavy, you probably will want 
to divide software changes into class I and class II changes. 
Class I changes would require full government configuration 
control board approval in the same manner as hardware. These 
could be defined to include those affecting: 

a. Contract specifications, price, fee, weight, delivery, 
or tests. 

b. Contract reliability. 

c. Performance. 

d. Interchangeability. 

e. Safety, 

f. Electrical interference. 

g. GSE. 

h. Facilities. 

i. Operational computer programs. 
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The class II changes would be those not covered above. 

They should be coordinated between the government and the 
contractor but would not require change board action. They 
would be changes such as make-work changes having a software 
effect only and not causing a cost or schedule impact. These 
are generally given automatic approval after the government 
technical organization has had time to examine them. 

Flight program software control and verification require 
careful control. A program verification plan should be written, 
extensive ground testing accomplished, and tight control im- 
posed. Remember, a misplaced hyphen can destroy your whole 
flight. 
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I I . Data Management 


The data management subsystem is sometimes called 
documentation management and sometimes information data 
management. In any case, we are referring to all of the 
management and technical reports which are requirements of 
the project. These usually are listed on Data Requirement 
Lists (DRL's) and Data Requirement Descriptions (DRD's). 

We are not covering here either flight data or computer 
data, per se. These are often handled differently. Data 
recording and data reporting is one of the most expensive 
aspects of the project. Obviously, it is required. Manage- 
ment at the project level needs data to adequately measure 
performance. Requests for contractor data, however, are 
subject to gross misuse. You must determine what kind of 
data meets your needs and how it should be displayed 
graphically so as to communicate to management. It is easy 
to get widely overlapping reports, reports that are not 
needed or used, and reports that are not timely. It is 
natural for each organizational element and each discipline 
to want their private report which covers what they desire 
and can be used to influence the project in their area. This 
makes it apparent that data management must be organized 
and not allowed to grow indiscriminately. It usually re- 
quires a specialist in the field early in the project. He 
can earn his salary many times. 

Since so many items are needed at the beginning of a 
project, it is customary to slight data management. If it 
is considered, it is usually an additional duty for some 
busy person. The approach then is to put out a paper asking 
what reports are needed. Later in the project someone is 
given the job of reducing the number of reports in the pro- 
ject. This is not the way to conduct data management. 

At the beginning of the project a data manager should 
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set the objectives of the project data management and 
then draft a list of the reports, documents, etc,, necessary 
to accomplish these objectives. Your objectives for data 
might be tot 

a . Keep management informed on a day-to-day basis of 
cost, performance, and schedule status. 

b. Isolate management problems in cost, schedule, and 
performance. 

c. Provide early warning of potential problems, 

d- Establish criteria for work around plans. 

e- Provide for exchange of management information. 

f. Promote management discipline and teamwork. 

Once you write out your objectives, it is not clear that 
you need the dozens of different reports that easily become 
attached to each project. A lesser number of reports, pro- 
perly organized can meet your goals. Remember the number 
and size of your reports determine cost regardless of 
repetition within a report, or ease of publication. Also, 
remember there are many sources of data — working groups, 
meetings, letters, TWX’s, etc. 

So much project information is now computerized that you 
should give thought to how much information can be picked 
off and displayed in real time by your own organization. 

Where this is possible you do not need detailed reports at 
a later date. For record, you can combine the summary 
information from several areas into one report. 

It is hoped that you have been impressed with the fact 
that data is needed. Not only that, data is vital to the 
project, but it can easily get out of hand. For the remainder 
of the discussion on data management, a list of data used 
at one time or another on one project will be listed. This 
list does not include many reports which were not formally 
placed on DRL T s , nor does it include reports, the requirements 
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for which existed for only a brief time span. The purpose 

of this list is threefold. It will display for you how 
many reports you can easily procure for one project if you 
do not plan carefully and desire a lesser number. It will 
show you the many areas of overlap. Lastly, it will help you 
manage the other side of the problem-obtaining the reports 
that are needed, in time, and in a useful manner. By studying 
this list you should be able to give guidance to your data 
manager that will allow your project to optimize the data 
it has and uses-in time to be included in the contract. 

PROJECT PERIODIC REPORTS 

Management 

Weekly status reports 
Monthly status reports 
Spacecraft management report 
Launch vehicle weekly reports 
Launch operations weekly reports 

Schedule 

Monthly status report 
Monthly schedule outlook 
PERT/SARP schedule report 
Project schedule outlook 
PERT status report 
Monthly PERT report 
Official flight schedule 
Hq. Schedules, SARP edition 
PERT launch status 

Procurement/Contracts 

Monthly change order and status report 
Procurement milestone status report 
State of contracts and grants 

Data Management 

Input report 
Magnetic tape 

Configuration Management 

Identification index and modification status 
report 

Management report 
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Logistics 

Monthly spares status 
Management report 

Facilities 

Preliminary engineering facility report 
Preliminary engineering reports by Centers 

Manning and Financial 

Project authorization 
Project allotment authorization 
Status of contracts and operation of 
installation 

Financial status of project, obligations, 
commitments and costs 
Object class reports 

Technical Description and Systems Engineering 

Quarterly weight and performance report 

Weight and performance summary 

Safety report 

Safety management report 

Safety problems report 

Maintainability report 

GFE status report 

Reliability and Quality Assurance 

Quarterly status report 
Failure report 
Management report 
Quality assurance report 
Quality problems report 

Testing 

Flight readiness reviews 

FRR summary data books 

Post launch reports 

3 day evaluation reports 

10 day reports 

Final flight reports 

3 and 10 day flight result TWX T s 

Launch vehicle flight report 

GSE launch report 

Reports of all major hardware tests 
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Site Activation Reports 
Flight Mission Operations 


Pre-launch report 
Post-launch report 

Failures and anomalies listing report 
24 hour flash report 
30 day failure and anomaly report 
Preliminary and reference trajectory report 
Predicted operational trajectory report 
Revised trajectory documentation plan report 
GSE evaluation report 

Project Planning (Current) 

Planning and alternate schedules report 
Control milestone schedule report 
Working launch schedule report 
Software flight development report 
Updated launch vehicle working schedules 

Spacecraft and launch vehicle major tests working schedules 

Launch vehicle assessment summary 

Launch operations report 

Spacecraft deliveries report 

Spacecraft working plans 

Spacecraft working schedules 

Project schedule effectiveness report 

Performance index report 

Mission selection status report 

Configuration Management Control 

Launch vehicles configuration differences report 
Spacecraft configuration differences report 
CCB open changes report 
Accident review board findings 

Engineering 

Weight changes and weight data report 

Weight and performance mission report 

FRR open items report 

Action item status reports 

Major problems report 

Major open items report 

Manufacturing 

Failure trends report 
Management status report 

Resources Report 
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Remember this list does not include onetime reports, 
flash reports, any of the planning reports in the Project 
Plan, etc. In a larger measure, it does not include the many 
technical reports intended for the technical organizations 
below your level . These then are the reports you are expected 
to see or at least to cope with. Individually each serves 
a purpose. It should be clear that data management requires 
considerable constructive and early planning* It requires 
some dedicated guidance and managing. It will require some 
difficult decisions. 

Data management cuts across all functional areas and 
overlays a set of disciplines which govern and control the 
preparation and delivery of contractor data. It does not 
in itself generate or produce data. Rather it is a standard 
"way of doing business." Data requirements should result 
from, and be subservient to, related tasks in the statement 
of work. 

As in most areas the overall system should be controlled 
from a project data plan. If a Center plan is not sufficient, 
it should be prepared by the Project Data Manager. It should 
describe the system used in the project to include the 
responsibility in staff and line elements for carrying out 
the plan. It should describe the use of the data require- 
ment list, the data requirement description, the request 
for data, and the Document Information Record (DIR). It 
should insure compliance with the requirements of higher 
headquarters. It should insure control of the key documents. 
It should provide for continuous review of data requirements, 
since initial requirements should decrease as the project 
progresses. It will help keep the problem before the eyes 
of all key people. Some Centers have the instructions for 
procuring data laid out in great detail in Management Manuals. 
These describe all of the steps, the abbreviations, the pro- 
curement process, and the kinds of data you may desire, in 
great detail. They are not always the full answer in data 
control, but will be helpful wherever they are available. 
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12. Reliability and Quality Assurance (R&QA) 


In general, the R&QA activities are pretty well organized 
throughout NASA. Further, you seldom find a NASA management 
document or project document that doesn't have separate R&QA 
sections. Much has been written on the subject so the above- 
mentioned documents are also usually complete with references. 
The problem with R&QA usually is not where can you go to find 
something about the subject, but rather how do you boil the 
R&QA subject down to something you can understand and how do 
you integrate R&QA into your project? 

Even though reliability and quality are well treated in 
NASA, the approaches to these subjects in their detailed pro- 
cedures are less stable than many recognized disciplines. Much 
of this is because NASA's one-of-a-kind requirement departs 
from production techniques previously understood. Also, R&QA 
organizations from the top down are under constant review 
since they are related to all other hardware efforts regardless 
of discipline. Every center has specialized groups to assist 
the Project Manager in this important area. The projects at 
Centers which previously just relied on proven concepts have 
grown in size and complexity, so these Centers now have taken 
up formal approaches to R&QA. Most Centers have a Center policy 
group and then another group concerned with data and procedures 
which is in the technical organization. In addition, it is 
NASA policy to make maximum use of DOD quality control offices 
in contractor plants. These three organizational areas will 
be of considerable help to you in accomplishing the total 
tasks. 

The objectives of NASA's R&QA program are to achieve 100 
percent success in space flight missions. Though this seems 
obvious, it is relatively new. In other types of programs, 
to accept some failures is economically a better approach. 

In NASA, it is not. This attention to quality and reliability 
has increased NASA's flight successes from around 52 percent 
in NASA's early flight years to over 95 percent in recent years. 


92 



The responsibility for quality and reliability in your 
project is yours. Headquarters and Center reliability and 
quality offices just guide and assist you. Their services 
may include assistance in preparing R&QA sections of the 
work statement and contracts, helping to establish environ- 
mental test levels, participation in testing, numerical re- 
liability assessments, maintenance of qualified parts lists, 
reliability reviews, failure reporting, engineering design 
support, instrumentation support for testing and flight, 
problem assessment, overall program evaluation, and mission 
evaluation. In accomplishing these general tasks there are 
a number of specific task areas where they can be of major 
assistance. These include preparation of FMEA's (Failure 
Modes and Effects Analysis) , establishing single point fail- 
ures, preparing limited life lists, preparing status and 
waivers lists, preparing qualified parts lists, checking 
pressure vessel histories, overseeing critical process pro- 
cedures, overseeing subcontracting procedures, reviewing 
design specs, in-process inspecting, controlling fabrication, 
and auditing. One can see that this is a major source of 
assistance that one cannot afford to do without. One can 
also see that these areas overlap or cut across all engineering, 
manufacturing, and test disciplines. Since R&QA offices 
will exist in your organization, as well as in other govern- 
ment organizations and, also, in the contractor organization, 
there is a potential source for friction and major misunder- 
standings concerning responsibilities. A somewhat normal way 
of handling such responsibilities is to have your own R&QA 
office work out the various interfaces. A word of caution 
here. You are interfacing many proud and senior offices. 

Your own office will naturally want to retain a position of 
influence and you may get off to a bad start. You or your 
deputy may want to assist with this organizing - or one of 
you may want to be designated permanently a senior contract 
in R & QA matters. 

The NHB 5300 series is, of course, the BIBLE for the 
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R&QA. Actually, these are excellent documents and, as with 

most documents, arc subject to interpretation. They have 

been invoked enough times now that neither the government nor 

the contractor should claim problems of interpretation. Cost 

may preclude buying everything in the series, however, so 

both the government and the contractor should be clear on 

which parts are purchased and which parts are omitted. Besides 

the overall documents in the series, there are specific documents 

such as NHB 5300. 4(3A), the special quality requirement for 
23 

hand soldering. 

Anyone with project experience soon realizes it is the 
seemingly simple change or improvement that causes failures 
later. An apparently straight forward improvement often in- 
validates the entire test program. Where innovation and 
new ideas are the theme in advancing the state-of-the-art, 
you may well improve your reliability by staying with a 
proven design or a proven part unless it proves faulty under 
test or unless the gain in performance or cost, if a change 
is made, is indeed large. Considerable information is avail- 
able on the joint NASA-DOD parts program. These programs are 
labeled Interservice Data Exchange Program (IDEP) and Failure 
Rate Data Exchange Program (FARADA) . Coupled with the thoughts 
on using proven parts for reliability is a similar trade off 
on redundancy. To a reasonable point, redundancy can greatly 
improve reliability. 

Since in the early portion of a project you are literally 
overwhelmed by the statement of work, contract negotiations, 
etc., it is easy to become completely absorbed with the prime 
contractor. In. such cases it is easy to overlook the hard- 
ware designed or manufactured in-house. Further, since you 
have a definitive contract with the prime contractor, it is 
sometimes easier to specify what you desire on the outside 
than from the inside. Since all government furnished flight 
items must stand the same flight rigors as contractor items, 
it is necessary they be built, inspected and tested to the 
same standards. You must insist that your Center R&QA 
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offices exact the same requirement from in-house flight 
items as from the contractor. If a r eliability or quality 
contractor, separate from the prime contract, is used, it 
may be even more difficult to balance these programs where 
parts are derived from many sources, to include in-house and 
out-of-house. In such cases, the R&QA reporting program and 
the review program (always important) become fundamental. One 
way to insure that you utilize the many organizations involved, 
the many sources of parts, and the many disciplines is to 
organize key R&QA people in a matrix organization so that a 
key person handles a functional area for each key piece of 
hardware. Such functional areas might include R&QA planning, 
reliability, quality assurance, component qualification, 
reliability assessment, reliability modeling, and failure re- 
porting. There are many breakouts which could be utilized to 
include in-house and contractor parts equally. 

It is apparent that R&QA is broad and diverse. It is a 
source of many potential problems throughout the life of the 
project. Besides careful organization to get people properly 
involved with the many technical areas, the best step you can 
take with R&QA is to insure proper in-depth planning. The 
quality area should include: 

a. Review of contracts and procurement requests to insure 
quality provisions, 

b. Surveying contractor plants to insure capability, 

c. Inspecting hardware at various stages, 

d. Maintaining control of the configuration, 

e. Arranging for failure analysis work, 

f. Handling malfunction and corrective actions, 

g. Participation in design reviews, 

h. Training, 

i. Assessment, 

j . Establishing loads and testing, 

k. Maintenance of parts lists (qualified, etc.), and 

l. Quality reviews. 
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The reliability areas of the plan should include: 

a. Design reliability goals and assessments, 

b. Failure mode analysis, 

c. Need for design documentation, 

d. Requirements for preferred parts, 

e. Workmanship standards, 

f. Test program scope and plan, 

g. Malfunction reporting plan and procedures, 

h. Applicable documentation required, 

i. The system of reviews, 

j . Soldering requirements, 

k. Special requirements (pressure vessel, pyrotechnics, etc.), 

l. Special requirements for analysis, and 

m. Test requirements. 

These, and other subjects you know to be applicable to 
your project, should insure a complete plan. A complete 
plan, well staffed, will assist in the understanding of inter- 
faces and responsibilities. 
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13 u Testing and Test Management 

Because NASA’s space flights utilize hardware that is not 
only "one-shot”, but usually one-of-a-kind also, the statis- 
tical approach to testing which has been developed for mass 
production items and weapons is not applicable. Actually, 
testing is an essential ingredient of the successful flight 
programs that NASA has conducted. NASA has shown great 
initiative, simulating practically every condition that the 
hardware sees during flight. 

Testing is performed to insure that all systems are work- 
ing properly and that the systems satisfy the requirements 
against which they were designed. These tests, amplification 
of NASA's test requirements, are designed to detect and 
correct actual or potential failures and establish functional 
capabilities of hardware systems and equipment that will be 
required to operate in space. Acceptance tests, such as 
functional, vibration, shock, and strain tests are required 
at proper points during the manufacturing cycle. Testing 
of the completed major systems is usually performed, at several 
government and contractor sites. These sequential tests, 
usually participated in by NASA, are designed to determine the 
readiness of space hardware. The requirement is to successfully 
complete these tests before you accept the hardware. This is 
aided by the fact that each level of hardware test and check- 
out requirement must be amplified to serve as a check on all 
possible prior activities. 

The testing function in a major project is a very broad 
one. Headquarters guidance outlines the general policy, 
philosophy, and responsibility. The appropriate NHB series, 
for instance, NHB 8080. 1A, sets general policy, and among 
other things requires that you write a detailed project test 
plan. Since testing includes development testing, quality 
testing, compatibility testing, reliability testing, environ- 
mental testing, acceptance testing, systems testing, and 
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several other categories, you must plan well to avoid 
duplication and yet to insure your testing is complete. 

Thorough testing is a vital part of project development. 

It must be done well by you and the contractor. You need 
to have talented people in your test office and you will 
need to devote considerable time to this area also. A good 
way to get the most from your personnel and the contractors 
personnel is to make some goals and objectives of your test- 
ing quite clear. A suggested list of goals you can consider 
is to : 

a. verify that systems, subsystems, and components 
meet design requirements. 

b. verify that hardware samples meet performance 
requirements . 

c. eliminate defects in design, material, and work- 
manship. 

d. discover unexpected interactions between sub- 
assemblies, particularly when exposed to environ- 
mental conditions. 

e. demonstrate that GSE and data processing equipment 
are compatible. 

f. train appropriate personnel. 

g. evaluate logistics capability. 

h. completely evaluate coordination. 

There are a number of test issues that can arise and 
that you should watch for. One of these is the logic of the 
test sequence. Some technical personnel will have features 
of a test program which they have learned should be emphasized 
such as low frequency vibration tests. Also, some personnel 
will be stronger than others and cause emphasis to be given to 
black box testing, or mechanical testing, or other parts 
of the program. These types of items can easily unbalance 
your project. You should utilize your project test plan as 
the means of analyzing your test program for logic, completeness 
and sequence. This requires careful analysis. 
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Another potential problem is component testing. It is 
difficult to write a contract dictating when component 
testing will be completed. You are then stating when many 
designs will be completed, when many pieces of hardware can 
be built, and when component testing can be successful. As 
a result, the contractor has considerable freedom in component 
testing schedules. He does not have this freedom with major 
flight and test hardware deliveries. The result is that there 
is considerable demand for the initial deliveries of flight 
type components. If the components go into assemblies instead 
of testing, you will undergo high costs in changes which must 
be retrofitted. You must see that component development 
testing is emphasized and supplied with sufficient hardware. 

Often the peculiarities of your project eventually require 
certain tests that were not recognized early in the project. 

When these tests are rushed late in the project, you will not 
only have higher costs, but you are subject to mistakes from 
hasty planning. Examples of such tests would be a dynamic 
test to cover a launch condition, or a major structural test 
where a failure has occurred, the structural data previously 
being built up by analysis from a number of structural component 
tests. All possible effort should be expended early in order 
to foresee these difficulties. 

Another testing problem is overlooking environmental 
conditions. Environmental tests have become somewhat stereo- 
typed. We step through vibration, fungus, etc., according to 
existing plans. Particularly, in larger elements, tested 
for certain features, we do not realize it may be necessary 
to consider all conditions the hardware sees. For instance, 
in structurally testing honeycomb bonded to the skin, we 
may be testing at ambient and find the skin heats and weakens 
during flight. 

Another problem, potentially, is that of organizational 
interfaces at a test site. When a number of organizations are 
utilized at a test site, it is worth being careful when tests 
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aro scheduled. Often these problems can be circumvented by 
stopping through the test months ahead of actual testing. 

Where the government and contractor both have responsibilities, 
great care must be utilized to see that responsibilities and 
duties are understood by each. It is very difficult to under- 
stand failures when responsibilities are mixed, i.e., the 
government builds a test stand and the contractor conducts 
the test. 

When a contractor is graded on the test program, i.e., 
part of his fee is attributed to points earned during the 
test program, you can expect difficulty in awarding these 
points. For instance, if development tests are graded one 
must expect certain failures during such testing, but if 
overruns are incurred or schedules not met because of develop- 
ment tests, you must have prior study and understanding of 
where dividing lines fall. 

During contract negotiation, a clear understanding of 
test levels must be delineated. Since you have not experienced 
flight testing, if you state that testing should be accomplished 
to the levels experienced in flight, then you are leaving it 
to someone to guess what those levels are. It is better if 
the government organization, together with the contractor 
if possible, set these levels according to the best judgement 
available, and differently according to the test levels ex- 
pected for each portion of the spacecraft. Also, in vibration 
for instance, if you expect 2 g’s at certain frequencies in 
an area of the spacecraft, do you test to that level for a black- 
box mounted on the skin? It may be that is the level going 
into the skin and there may be further amplification by the 
skin. Therefore, a complete test analysis, box by box, must 
be accomplished in time to negotiate it into the contract. 

If it is impractical to have these analyses completed prior 
to negotiations, then the Government should specify the range (s) 
expected, therefore precluding unnecessary contract modifi- 
cations at a later date. 
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You must a] so take into account the effect of your 
test program on other activities and the effect of these 
activities on your test program. For quality or reliability, 
when these are run as separate programs there is usually 
an in-depth test program connected with one or both. It would 
be improper to conduct quality testing under one program and 
development testing under another without coordination of 
objectives, facilities, and tests. Wherever possible ALL 
programs should funnel in separate requirements and then 
only one set of tests per type be conducted. In doing this 
do not forget periphery programs such as value engineering. 
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14. Safety 


The need for safety is obvious, but with the advent of 
manned flights the launch hazards of sophisticated vehicles, 
safety has received renewed emphasis. All Centers have safety 
offices, but they are involved in flight projects to different 
degrees. Of course, the manned space flight Centers stress 
safety more because of manned flight. 

Safety, per se, is hard to treat since it is not a new 
and different discipline. It begins with design, proceeds 
throughout the test program, is reflected in the reliability 
and quality standard applied to the equipment and culminates 
in the meticulous checkout of the vehicle and the rehearsals 
of the mission prior to flight. Safety offices are responsible 
for such items as safety policies, standards, criteria and 
procedures and for maintaining a high level of safety awareness 
and visibility. The safety office jurisdiction includes hard- 
ware, software, tests, flight tests, investigation boards, 
reviewing plans, review checkout documents, total development 
analysis, participation in reviews, review of facility plans, 
and other aspects of the project. 

You can see that safety can involve every aspect of the 
project. This leads to some do f s and don’ts. Your Head- 
quarters and Center Safety personnel can be a big help to you. 
They are not involved in daily management of the project and 
yet they participate in almost every aspect. They will have 
an insight that you do not have. They can be additional man- 
power that will assist in seeing something you missed. 

On the other hand, a group such as a safety office usually 
is more effective if it is small and operates as a detached 
view of the development. If an unsafe act occurs and alarms 
everyone, you should be careful of overreacting. For instance, 
asking a contractor to develop a safety plan and thus giving 
him an opportunity to employ a large number of people in all 
project disciplines and restate the development plan under a 
safety cover is not generally useful. Funds spent on safety 
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ought to be for redesigns, or replanning, where a concrete 
deficiency exists. Also to hire a large number of support 
personnel so that a safety office can have personnel in its 
many areas of jurisdiction is usually not the best use of a 
large expenditure. A small, top level crew moving from phase 
to phase will see the changes that are needed better than having 
a safety man stay with each group. 

The playing down of large expenditures for safety does 
not mean, however, that you should play down safety. You 
should cultivate the Headquarters and Center safety offices. 

If they are not directly involved in your project you should 
attempt to get them involved. You can help by making arrange- 
ments for them to be allowed in closed tests or to participate 
in design reviews. Better still, give them suggestions where 
you are concerned but have not had time to check and let them 
be your other eyes and ears. Good rapport on safety will pay. 



15. Logistics 


One of the biggest problems with Logistics is that more 
often than not it is overlooked. It has been pointed out in 
earlier chapters that there are very few publications that 
assist a Project Manager in other than policy areas. The few 
that do exist and the policy manuals generally have in common 
the fact that they do not discuss logistics. One logical rea- 
son for this is that the military application of this term 
stresses support in the field after R&D and when the system is 
under procurement in quantity. 

In the military also, however, logistics covers support 
on a broader front. In R&D, a broad definition would be 
everything needed to support the R&D effort and the personnel 
involved. A more practical approach would be to say everything 
not covered by other distinct organizational areas. For in- 
stance, personnel, data, computer support, etc., could be 
construed as logistics, but if they are covered by your organi- 
zation or the Center, there is no need in also having a logistic 
group cover them. There is a need to have someone particularly 
watch out for areas not otherwise covered by the organization. 
This does not necessarily mean you have to have a logistics 
reporting to you. It does mean you should designate 
someone in your project office or your engineering office to 
cover logistic areas which are otherwise not clearly assigned. 

A short study could determine the areas needing coverage. 

This would lead us quite naturally to want to know what 
things might be logistic in nature and might not be covered 
by other parts of the organization. Just to list some of the 
possibilities we can include: maintenance, spare parts pro- 

visioning, supply support, maintenance spares, operations and 
maintenance instructions, launch and test site engineering, 
and training. There may be others not covered and some of 
these may already be covered by your particular organization. 

Too often in the development of a difficult project, one 
becomes concerned with the design objectives at the expense 
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of logistic needs. Looking at life cycle costs causes system 
planners and engineers to consider the testing and launch costs 
and problems. In the launch mode, the function of maintenance 
becomes one of the strongest factors in determining the need 
for personnel, facilities, supplies and transportation. The 
cost of maintenance is directly related to complexity, reli- 
ability and ease of maintenance. One of the largest cost ele- 
ments is the training and retraining to a required high skill 
level. To consider these features, logistics thinking must be 
integrated with design thinking. In many major contractor 
approaches the logistic thinking is either listed generally 
under resource requirements or is covered by the entity con- 
cerned, i.e., test operation, launch operations, etc. As such 
it is difficult to ascertain that a trade off is really being 
made to balance design with later logistic requirements. This 
can result in more effort and cost during operational phases 
than you had planned on. 

Sometimes, when it is apparent the operational phase will 
be critical the logistics may be well covered. A good example 
is the Space Shuttle RFP, since the Shuttle is being designed 
to operate for a number of years. The Shuttle RFP gives the 
requirement this coverage: "The Contractor shall implement, 

operate and maintain a logistic management system for support 
of the vehicle and ground activity. This effort shall, as a 
minimum, include spares management, analysis of support require- 
ments, training, inventory management, repair and overhaul, 
propellants and gases, identification and utilization management, 
warehousing and storage, transportation, and support activities. 
The contractor shall recommend procedures for and participate 
in a NASA integrated logistics management system. Low cost per 

flight should be uppermost, consistent with safety and 
24 

reliability . " Such a start will at least ensure logistic 
consideration at the proper time. 

Most large projects, particularly if several launchings 
are involved, should prepare a logistic support plan. Then 
you will have an orderly approach and avoid gaps and overlap. 
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It will help you identify and utilize your resources. It will 
help you systematically develop requirements based on needs. 

It will assist in controlling configuration and interfaces. 

It will save costs through preplanned maintenance and main- 
tenance consideration during design. It will ensure spares, 
field support, manuals and training when needed. If you have 
several pieces of hardware at the level below you, possibly 
each with its own manager reporting to you, a logistics support 
plan will ensure the uniformity you must have. 

Maintenance planning should give consideration to scheduling 
of maintenance, to failures occuring during scheduled activities, 
to performing analysis to identify maintenance functions and 
levels, to accessibility, to malfunction detection, to fault 
isolation time goals and to spares requirements. Maintenance 
requirements must also consider all GSE. In addition to main- 
tenance, spares provisioning is a separate subject. There are 
many considerations here. Spares are usually considered as 
maintenance spares (those installed on flight articles, etc., 
on-site) , repair parts (to bring a part back to serviceable 
condition), and standard parts (off-the-shelf). These require 
different considerations. Obviously, standard spares have a 
shorter lead time than special items. It will take a careful 
maintenance analysis to determine how many special spares must 
be procured, and when. You must consider failure rate, quantity 
of item used, maintainability characteristics, procurement lead 
times, turn around time, criticality, and cost. Over supply 
of spares can be very costly; undersupply can be disastrous 1 . 

You should publish your decisions on spares in a provisioning 
document so that everyone understands the situation and so that 
you have uniformity. This will also assist you in keeping up 
with changes to your spares list brought about by changes to 
end items and by experience during tests. 

The Operating and Maintenance (O&M) instruction manuals are 
organized sets of procedures that specify the method of operating 
and maintaining the equipment. These documents should indicate 
skill level requirements, show the time restraints, prescribe 
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the limitations of design specifications and configuration 
changes and ensure performance. If more than one piece of 
hardware is involved for your project, particularly if the pro- 
ject is launched by a single launch team, the O&M manuals will 
be of great assistance in standarizing procedures for a uni- 
form approach. They also provide the means of integrating 
maintenance with standard configuration management procedures. 

Training is an integral part of logistics. This is not 
optional training but technical training to provide the neces- 
sary trained personnel for proper system operation and main- 
tenance during assembly, checkout , test, and launch activities. 
The program results from an analysis relating tasks, operation, 
skills and procedures to requirements. 

A caution! If you are using your prime contractor to de- 
velop your logistics plan, do not forget your GFE items. GFE 
must be subjected to the same analyses and spares provisioning 
as flight items. Particularly if these items are designed or 
procured by in-house laboratories and there is no logistics 
plan, it is very easy to overlook the costs associated with 
GFE logistics. 

Another thought that should be applied early in the project 
is to think of maintainability as a part of logistics. Main- 
tainability is a characteristic of design and installation which 
can be expressed as a probability that an item will be retained 
in or restored to a usable condition in a period of time, when 
the maintenance is performed in accordance with prescribed 
procedures and resources. The purpose of planning maintain- 
ability ahead of time is to reduce development time, reduce 
maintenance costs, cause design personnel to realize its im- 
portance and to be able to predict maintainability for later 
project stages. 

Particularly the quantitative nature of maintenance, pre- 
dicting the life of a part, the number of spares needed, etc. , 
is very relatable to quality and reliability. Good coordina- 
tion should ensure that your staff offices do not require two 
similar outputs under different headings. 
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16 . 


Facilities 


Facilities can refer to the facilities required to develop, 
produce or test the project or portions thereof. It can also 
include equipment acquisition, modernization and maintenance. 
Further, it can include facilities planning, design, layout, 
procurement, construction, installation and reporting. The 
time, therefore, to give emphasis to facilities is during the 
preparation of the RFP. Additional facilities are always the 
means for a contractor or government organization to expand its 
base. Such expansion is not always desirable, however. Unless 
specifically controlled, you can expect an organization to 
expand its facilities. Some expansion may be required and 
intended. However, the RFP must require that all facility 
planning be spelled out. The RFP is the time to specify the 
use of government owned facilities if that is the approach. 

It is also the time to specify any use of existing contractor 
owned facilities. Otherwise you may find these committed to 
another project when you thought they were available. A good 
approach is to specify in the RFP the facilities you want 
utilized and request a plan in the response for all other re- 
quirements that will be needed. This gives you an opportunity 
to change after you see the total problem. It also requires 
the contractor to think out the total problem ahead of time. 
Starting at the time of the RFP and continuing through contractor 
response, your office should start testing all facilities for 
every requirement, major increment of project work, and major 
project milestones. This should indicate their scheduled 
availability and/or lead times. This permits you to be sure 
of coverage. Also, where you know of tight spots in the project, 
it will prevent your having planning which is too large. You 
should make this assignment early in the project. 

Both NASA Centers and the Aerospace contractors tend to 
centralize their facility organizations. In the case of the 
contractor, usually a matrix type organization exists where 
the chief of facilities reports to management and a lower level 
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individual is concerned with project facilities. The only 
caution here is recognize that this organization is oriented 
to the company. You will probably have facility coverage, but 
you may not have the most economical coverage that can be con- 
sidered. In Center facility offices, you usually have capable 
well-oriented people who know the facility portion well enough. 
They cannot know the project well enough to obtain an optimum. 
There are two good solutions to this. One is to appoint some- 
one in your office to interface the facilities offices. The 
other is to get the facilities office to appoint a man to your 
office who is responsible to you. You will probably get good 
design and construction in any case, but only with someone re- 
sponsible to you, can you ensure that the project milestones are 
met, that existing facilities are fully considered, that project 
peculiar requirements are utilized, etc. If the facility con- 
cerned is a separate test or manufacturing facility, etc., it 
will have a separate contractor and/or government facility 
manager. This must be considered in cohesive planning. Also, 
there are many considerations and standards which only you can 
determine. Do you need to retain a capability to expand? What 
quality control conditions such as clean room, contamination 
control, etc. , need to be imposed. Can you dispose of 
facilities when they are no longer needed or do they remain 
charged to the project? 

Of course, major facilities are usually charged under the 
Construction of Facilities appropriation. This means two main 
things to you. Such appropriations are subject to a four- 
phase programming cycle with approval to initiate each succes- 
sive phase based on the results of the preceding phase. These 
phases are concept, preliminary design, final design and 
execution. Therefore, lead times for the whole project are 
incredibly long. Also since this is a line item appropriation 
to the Congress, you cannot reprogram when your needs change. 
These features mean that any new facility proposals will re- 
quire extensive review at NASA Headquarters and Congress. It 
is vital that your construction requirements be determined 
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early and correctly. The procedures In detail are set forth 

o c 

in NASA Procurement Regulations. One consideration in these 
regulations is that they state facilities are to be provided 
a contractor only in those cases where such provision is 
necessary to assure the performance of the production or 
schedules. This will cause contractors to propose company 
owned facilities be built and amortized over a short period 
of time. Although this arrangement is not generally advan- 
tageous to the government financially, it may be required. 

Since new facilities tend to expand and since R&D facili- 
ties have a tendency to be one of a kind, there is sometimes 
a desire to disapprove these new facility proposals if at all 
possible. There are some things you can do. You can make 
your survey of existing facilities as thorough as possible 
so as to leave no doubt as to need. You can also design the 
facility so that it is not so specialized — has a capability 
and need for continued use. 

Once a facility is approved, if it is major and its timing 
vital, you should develop a facility activation plan and have 
someone specifically in charge of it. If the facility is com- 
plicated you may want to have PERT control or some other visual 
means of control. Only by this approach can you ensure that the 
complex final steps of the contractor mesh with your early 
activation steps. Remember your organization will provide con- 
ceptual design; then an architectural and engineering con- 
tractor will provide detailed facility drawings and 
a different, competitively selected contractor will be awarded 
the construction. Unless you were thorough with the concept 
design, at the time of beneficial occupancy you may not even 
recognize all of the final facility. 
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17. Maintainability and Producibility 


This is a subject under logistics also, so not too much 
more need be said. However, as with other subjects treated 
here it is worthy of a separate heading so you will consider 
it in your initial planning. Maintainability and Producibility 
not considered early will not be worth considering. 

First, you should be sure these items are a part of your 
RFP. Words like "They should be considered in the design" 
may be good enough, but it will piobably take stronger language, 
such as possibly considering the subjects in incentive con- 
tracts. The contractor should at least have to describe his 
plans. We must always remember that the success of U.S. 
industry is built under the profit motive. Industry must 
treat first those things affecting profit. Left to its own 
devices, ease of maintaining and producing are not first order 
considerations. 

There are a number of other things you should do. Most 
of these are addressed to maintenance, but they facilitate 
producibility. You should ensure that the levels of main- 
tenance are thought-out and set up. This dictates what is re- 
paired on site and what is replaced. It tells you where your 
skill levels must be. With no thought you will probably estab- 
lish skilled maintenance at too many levels - or possibly too 
few. Maintenance levels are an aide to scheduling maintenance 
by time and serviceability. 

Once the prime contractors are selected and you have your 
staff thinking in terms of levels and echelons of maintenance, 
it is time to stop and have a thorough maintenance and produci- 
bility analysis made in detail. This should be accomplished so 
as to uncover problems in preliminary design. It will identify 
bottleneck support requirements, new equipment needed, and 
show unusual spares requirements. Such analyses will identify 
design trade off while there is still time to judge if costs 
of producing or maintaining warrants a change. These analyses 
should consider production methods, tooling requirements man- 
hours required, accessibility, malfunction detection, fault 
isolation time goals, spares requirements, GSE requirements, 
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and training requirements. 

These are not very glamorous studies while you are in- 
volved in early design. They probably should be performed by 
your prime contractor unless you have an unusual in-house 
capability available. However, you will need to have one of 
your staff watch this effort from the beginning to ensure it 
accomplishes your purposes. You should end up with parts that 
are easily produced without undue cost or time for any portion. 
Your maintenance analysis should end up with a set of operating 
and maintenance manuals. 

Some of the features you should accomplish in the above 
program will include: 

a. Reducing development and production times. 

b. Increasing the project effectiveness. 

c. Reduce producing and operating costs. 

d. Keeping people aware of the importance of this area. 

e. Improve your reliability predictions. 

f. Avoid serious problems late in the project life. 

If you think of maintainability as design, done in such a 
manner that the system can be maintained or produced within 
the allowable time and at an acceptable cost, this will let 
you do your analysis with some goals in mind. Your analysis 
can be more like trade studies where design, requirements, 
flow, etc., can be analyzed against time and money. 

It is not expected that this discussion will surprise you 
by the features discussed. It is only intended to refresh 
your mind on these subjects so that you will have a few sub- 
elements to prompt them with. You probably cannot spend a 
great amount of time on these elements but someone must. 
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18. Specialists 


Project management has become more and more technical and 
more and more complex. One natural outcome of this is the ac- 
quiring of specialists. These specialists may be highly in- 
volved directly in the activities of a particular project and 
in such cases are generally assigned in the project office. 

They may cut across the activities of several such projects 
and thus may be assigned to the Center staff or to the labora- 
tories or engineering organization. In any case you should 
survey your project or have such a survey made, to determine 
how many specialists you have involved with your project or 
how many you should have. 

You can look at specialists in two ways. One, they are 
additional manpower that through their discipline see your 
project in a different light and thus contribute to the progress 
of the project. Two, they are a drain to the resources of your 
project. They may cause a manpower drain, and they are almost 
sure to cause a financial drain to some degree. 

You should, after listing the involved specialists, set 
policy for their use. This is somewhat like contributing to 
a number of welfare agencies, particularly before consolidation. 
There is some overlap, a few you don’t believe in, but in 
general it is a good cause so you determine what you can afford 
and how you want to prorate that total. It is generally not 
good enough to let this subject drift and face up to each 
specialization as it occurs. A strong specialist may spend 
more project funds than his specialty deserves. Others, 
which are important may be weakly represented or not at all. 

By not checking the total you may underestimate and not be 
financially covered. This brings up an organizational point. 

If the Center is not covered in a particular specialty, you 
may need to devote a specialist to the job, if it is important 
to the project. If most of these specialists do exist some- 
where in the Center, you will probably want to appoint contact 
and commitment points in your own organization so that the 
activities remain balanced in the project. 
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Many of the specialists are so important to your project 
that they have been given independent coverage here. Even 
quality, reliability, and testing could be considered such 
specialist activites. A little less obvious would be safety, 
logistics, data management, and software. In any case, a 
number of areas such as these have been treated separately and 
are not repeated here. This section intends to point out the 
significance of a number of less obvious areas and bring them 
to your attention for your action. These can include, but are 
not limited to: Value Engineering (VE) , Technology Utilization, 

Human Engineering (flight items or GSE) , Standardization, 
Compatibility, System Security, Man Rating (if manned), Packag- 
ing, Transportation and others. It can include a different 
class of items such as Independent Research and Development 
(IR&D). Their classification is not as important as is their 
recognition of involvement with the project and hence use of 
project funds. To this end they should all be assigned and 
accounted for. 

A number of the specialties must be treated in the con- 
tract of the prime. Some of those treated separately may 
warrant considerable coverage in the RFP, i.e., software, 
quality, etc. Some may be covered by standard clauses in the 
RFP, just to be sure they are considered and included. These 
could include clauses on materials for compatibility, loads, 
handling fixtures, divisions of responsibility under trans- 
portation, approved parts lists, references under standardiza- 
tion, and so on. It is not intended in this section to go into 
each one of these specialty items since they are so numerous 
and varied. Instead, one such item will be discussed in a 
little further detail as an example of the considerations 
which must be planned and assigned. For this example, Value 
Engineering has been chosen. 

Value Engineering may be approached in two different ways, 
for any given item, depending on the status and nature of the 
project. One way is to provide value engineering techniques 
to products which have already been engineered. Usually more 
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pro !'i tub Ic changes can be determined at this stage. The second 
method pertains to projects under design which have not been 
fully engineered. This is the most economical time to apply 
Value Engineering. Value Engineering is generally covered in 
the contract of the prime, either under an incentive approach 
in order to encourage it or as a mandatory requirement with 
incentive as an added attraction. Delay means a decrease in 
savings so contract provisions must call for prompt evaluation 
of design and Engineering Change Proposals (ECP T s). The real 
cost and hence real savings is more than the production costs. 
If research is prompted to verify a VE principle, cost of this 
research will have to be determined as separately required or 
required for the VE purpose. 

Since a Value Engineering study is primarily to contribute 
to reducing cost of an item without jeopardizing performance, 
quality, maintainability, standardization, or interchange- 
ability, significant savings can be accrued. High caliber 
engineers are trained to see savings in design configuration, 
the manufacturing process, and the production tooling. Per- 
sonnel involved should have specialty training and show 
adaptation to the project. You must weigh the benefits and 
costs - to your project and decide. You must determine if 
you desire value engineering in your project, and if so, how 
deep in the project it should be organized. In any case, 
you should not let it be accepted by some personnel in your 
project, without thought or pattern. 


115 



1 9 . Pr ocur emen t 


Procurement is a broad subject. Of course, many of its 
features were discussed under the RFP chapter and other elements 
are touched upon elsewhere. However, the subject is so important 
and has so many important aspects, it should be covered sepa- 
rately also. 

One thing peculiar to Procurement is that, on one hand, it 
is just another element of project management, on. the other hand, 
its importance and good business requirements often cause it to 
be largely administered outside of the project organization. 

This is all the more reason why this subject must be understood. 
To start with, considerable procurement policy has been written. 
Briefly, the top level documents include the NASA Procurement 
Regulations, the NASA Procurement Policies, the Associate Admin- 
istrator Offices Instructions, and Field Center Policies. 26 ’ 27 
These cover regulations, plans, noncompetitive justification, 
SEB’s, impersonal services policies, deviations, mods, waivers, 
incentive contract guides, Cost Plus Fixed Fee (CPFF) guides, 
development plannings, letter contracts, milestones for pro- 
curement, change orders, and other areas you need to know. Even 
though procurement has some differences from other areas, it 
is still a vital and active area in the Project Manager's role. 

He leads in contract and contract change negotiations, in 
preparing and understanding the statement of work and speci- 
fications, in technical management and in administrative 
functions. He plays a major if not lead role in the negotiations. 
His role in procurement is a major order of business. 

This is a very complex area. You need an approach. You 
cannot be expected to keep up with all of these regulations. 

No one in your organization that you appoint can keep up. There- 
fore, the usual answer is that the Center Procurement Organiza- 
tion will help serve your procurement needs. From a technical 
point of view, this is sufficient. However, under the theory 
that a project manager needs to have control of all aspects of 
his project, you cannot afford to lose control in the procurement 
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area. The Center organization is interested in seeing that 
procurement is done properly and follows all regulations closely. 
You are also interested in these features and further interested 
in seeing that your project is accomplished as described. These 
aims can conflict. Two solutions are: either to appoint some- 

one to interface the procurement organization (for instance a 
section in your Project Control Organization) , or you can have 
the Procurement Organization detail to you a small number of 
specialists who would be sufficiently under your control so 
as to emphasize your requirements. Either way you go, you 
should have that group go back over all pertinent regulations 
to determine the items that particularly apply to your project 
and your circumstances, and then brief you. Also, they should 
plot all key procurement milestones for your project so you can 
plan for these key dates. They should also watch for project 
needs in the procurement area. A particular requirement which 
should not be accomplished by an outside organization is the 
preparation of a project procurement plan. Your organization 
should prepare this plan. It is needed in detail, and early in 
the project. This will bring you face to face with the issues: 
type of contract, any noncompetitive procurements, time schedul- 
ing, letter contract requirements, etc. You must control these 
procurement activities. 

When coordinating procurement matters, remember that every 
level is interested and involved. You will have to coordinate 
Headquarters Procurement Plans, justification for noncompeti- 
tive procurement plan, determinations and findings, deviations 
and waivers, contracts, advance approval of incentives, and 
letter contracts. Be sure you initiate these items in time to 
accomplish the needed coordination. You need to understand how 
many of your procurements exceed your approval authority and 
what approval levels are involved. You also need to know how 
many procurement plans will have to be prepared, and their 
time scales. It would be good for you to refresh yourself on 
the three funding levels, the various levels of responsibilities 
for procurement plans (about eight or nine levels total) , the 
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levels for justification of noncompetitive procurement, 
and the levels for contract modifications of different 
dollar amounts. It is possible also for your project to 
be involved in procurement outside of the above negotiated 
procurements. These include such things as standard issues 
(electrical parts, chemicals, etc., procured through the Center 
property stores) , consultant services through temporary civil 
service appointments or otherwise, and various supporting 
contracts . 

As you can see, your procurement activity is large and 
varied. Even so, a contracting officer is the final signatory 
authority on all contractual documents issued by a Center and 
is the only person authorized to contractually bind the agency. 
Many constraints are placed on that authority so that the con- 
tracing officer has limitations in doing what you want done. 

He has a major coordination constraint which takes valuable 
time. NASA Headquarters is concerned with shortening procure- 
ment administrative lead time. Even so, dozens of offices 
are involved, and it can take a painfully long time. You can 
do much to shorten this time! 

a. Familiarize yourself with procurement in general and 
your procurement activities in particular. 

b. Insure that procurement packages are complete. 

c. Be active personally in technical evaluations within 
your project. 

d. Schedule your requirements realistically and use 
emergency procurement action when necessary. 

e. Promote coordination among your office personnel, 
technical representatives, the financial analyst, and the 
procurement personnel. 

There are various quick reaction methods to get some work 
done when quick coverage is needed. These differ from Center 
to Center but they may include: 

a. Off site engineering design services. 

b. Technical writing services. 

c. Off site fabrication services. 

d. Computer programming services. 
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Most Centers have guidance on modifying existing contracts. 
For instance, Goddard Space Flight Center's GHB 5104. 2 A describes 
the procedure for modifying contract specifications, and it de- 
fines changes under the categories of mandatory, highly desirable, 
and optional and tells how to implement each. This handbook 
also gives details on providing technical direction for a course 
of action within the scope of the contract. Since small contracts 
have so much involvement with the procurement activity, hand- 
books such as Lewis Research Center's "The Management Control 
System for Small Contracts" are very useful, ^ 

It is interesting to note that some Center publications 
point out that a Project Manager could spend three-fourths of 
his total time on functions including or related to procurement, 
or monitoring contractor effort. It shows the extent and im- 
portance of procurement, and it shows the demand on the Project 
Manager’s time. As had been pointed out, cost information, 
abiding by the regulations, etc. , are primarily the duty of the 
Contracting organization, but you are primarily responsible for 
all such items, particularly for the specifications and state- 
ment of work and for monitoring contractor efforts to be sure 
these requirements are met. You must be involved with the 
whole process even though you can think of NASA procurement 
organizations as performance management and contract adminis- 
tration oriented. These two functions are interrelated and 
each affects the other. 

In summary, you are primarily responsible for the total 
performance management of your contract, including cost, 
schedules, and contractor performance. You must establish the 
lines of communication, formal and informal, with your con- 
tractor to carry out this function, to include reviews, and 
feedback. You must act to avoid contract cost overruns by 
monitoring analysis and action. You must act promptly on 
change submissions. You must adhere to the configuration man- 
agement system specified. You and the contracting officer 
must insure that reliability and quality practices are carried 
out. Your job is made harder by the fact the end item is seldom 
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precisely defined. NASA is usually pushing the state-of-the- 
art. This makes a policy for handling the contract even more 
important . 

You should use all of the contract standards possible, 
however, and utilize changes as little as possible. You may 
use all of the following for performance measurement standards. 

a. Tasks in the statement of work 

b. Design specification 

c. Performance specifications 

d. Process specifications 

e. Material specifications 

f. Project Plan 

g. Test Plan 

h. Manufacturing Plan 

i. R&QA Plan 

j . Configuration Management Plan 

l. Performance schedule 

m. Award Fee Criteria 

n. Delivery 

o. Use of the key personnel 

Measurements in some of the above areas will be subjective. 
Other areas of this report will discuss the analysis of progress 
which you must now make. 
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20. Project Records 


In addition to data management as a subject, you need to 
think about your record keeping. Of course, that is not a 
subject requiring many pages of thought, but it is set aside 
so you will apply some systematic approach to it. Like every- 
thing else it needs to be planned early. 

You can think of data management as the means of identi- 
fying and acquiring the minimum data to effectively manage the 
project. The project records are those periodic reports, 
special reports, film reports, plans and other forms of data 
which should be set aside for particular purposes. These pur- 
poses can include: 

a. Historical records. 

b. Data banks for current and future programs. 

c. Training materials. 

d. To assist other Centers. 

e. To assist in problem solving. 

It may sound like, from the above, that you should save 
everything, and if you don’t plan it you will fill many safes 
making it difficult to convert to systematic retention. The 
best way is to start at the beginning and compile a list of 
reasons for retaining project information. Your list will look 
something like the above. You will notice that although you can 
separate your objectives the material saved cannot be sub- 
divided so many ways. The historical data, data banks data, 
training data, and data of interest to other Centers will over- 
lap. Therefore, for your purposes you may want this filed 
under one overall heading by some type of subject listing. The 
problem solving data is technical in nature and may be listed 
separate ly . 

It is useful after you have gone this far to take one more 
step. List under the above two categories the types of data 
that should be saved, i.e., under the first category: unique 

management approaches, state-of-the-art problems, technical 
breakthroughs, lessons learned, unusual approaches, and probably 
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many others of interest to you. Under the technical problems 
you will probably want to retain data that may assist you 
in later problems, i.e., even if you have completed manufacturing, 
the number of inches of repaired welds in a cryogenic tank will 
be of interest until the last such vehicle has completed its 
mission. For the same reason, you will be interested in trace- 
ability of most critical materials. 

Once you have set such a pattern as this it probably 
will not be too hard to administratively carry out the 
actual retention. Possibly you can get assistance from such 
offices as the Center Historical Office. In any event, you 
will probably want to organize your office to this end. A 
simple way is to designate two or three secretaries who are 
in the flow of such records and instruct them on the type of 
material to be retained. A central filing location should 
be designated for all such material. In order to prevent 
this effort from growing out of proportion, it is helpful if 
the filing location is just part of some other central files 
that you require for other reasons. Lastly, designate someone 
to whom the above secretaries can look for decision in any 
areas of doubt. 

This may seem overdone for such a minor area. Perhaps 
it is. However, such files are eventually required for each 
project. They are either planned from the beginning, estab- 
lished later with an undo amount of effort, or the Project 
Manager must "beg off" the requested assistance or problem 
solving because the effort and tools simply aren’t available. 
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21. Experiments 


Those who have had a project carrying a significant number 
of independent experiments know that this is one of the most 
troublesome areas in NASA R&D. Those who have not been direct- 
ly connected to independently developed experiments may not 
realize or properly prepare for the potential problems in this 
area. Early planning for experiments will save much time and 
effort later. 

If you have the capability to carry experiments, it is 
axiomatic that you will have some and will have to set up 
some criteria for rating the experiments so that you can choose 
the best ones and eliminate the others. This is usually a 
rating based on overall worth and weight. You also may need 
to select categories of experiments since the experiments pro- 
posed may be scientific, engineering, or biomed (manned flight). 
In many projects this may be obvious, i.e., an astronomy satel- 
lite may not accept experiments that are not connected to 
astronomy. The selection process for experiments carried could 
cover a separate chapter. 

For those who have handled individually developed experi- 
ments you know that after selection of experiments the problem 
has just begun. Besides the diverse nature of the experiments, 
you will have many diverse requirements. They may have power, 
telemetry, cooling, weight, size, contamination, environmental, 
etc., requirements. They may impact the spacecraft access, 
the mission profile, the system tests, etc. 

In addition to having experiments developed at separate 
locations all over the country, it is to be expected that those 
who are inventing or developing are not project oriented. It 
is natural that they will be more concerned with the quality 
and success of the experiment than with schedules, funding, 
or impact on other areas of the project: These remain pri- 

marily your concern. 

We have then described a systems problem. With all the 
impacts on various parts of the project and with potential 
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individual problems, you need to go at it two ways, and 
you need to get at it early. The '’system” must be analyzed 
for requirements in power, telemetry, etc., and a reserve 
carefully managed. In addition, each experiment must be 
carefully monitored and tracked by an individual in your 
office. The purpose of this, primarily, is to understand the 
experiment and its progress and thus be able to anticipate 
delays, cost increases, new requirements for power, etc. The 
purpose is not to have the project monitor placed in charge 
of the experiment. Therefore, the selection of these indi- 
viduals must be done with care. 

The engineers from your office, who could be called 
experiment integration engineers, should provide assurance 
that the experiment and your project are technically compatible. 
They should be responsible for detecting any incompatibilities 
that may exist and to assist in resolving them. Specifically, 
they could be assigned duties such as: 

a. Conduct a thorough review of the experiment to project 
ICD for technical incompatibilities or omissions. 

b. Insure that the experiment integration procedures, 
interface definitions, criteria, etc., are complete and 
consistent . 

c. Review all waivers for technical accuracy, possible 
impact across the experiment interface, and for adequate 
coordination. 

d. Review all BID’S (Review Item Discrepancies) for 
technical accuracy and adequate coordination, assuring that 
all of the integration has been successfully closed and that 
they are satisfactorily resolved. 

e. Review the design flight plan for compatibility time 
lines and design requirements such as voltages, temperatures, 
etc . 

f. Review other system studies that involve experiments, 
such as safety analyses, sneak circuit analyses, etc. 

g. Review the requirements for scientific data. Negotiate 
data requirements with the Principal Investigator, to include 
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policies, data release, data reduction, analysis, and 
reporting mission results. 

h. Keep everyone, particularly Center technical personnel, 
informed of the status and potential problems. 

Most of the NASA R&D projects, as a whole, are engineering 
projects. You, for instance, are probably an engineer. Many 
of the experiments are scientific in nature and generally con- 
ceived and built under the direction of a scientist. In 
general, a scientist outside of your organization will inter- 
face better with a scientist in your organization than with 
the project engineers. He will feel such a person speaks his 
language and is interested in more than just producing some- 
thing to fly on time. If you can obtain, full or part time, 
the services of a project scientist, it can help establish 
the cooperation needed to achieve the overall goals. Some 
managers who have carried major experiments consider the 
requirement for a project scientist as mandatory. 

In order to treat all of your experiments as a system, 
there are a number of characteristics of each experiment which 
should be cataloged at the beginning. Although these require- 
ments will change, you can use the catalog as a control device. 

A checklist for this catalog might be as follows: 

a. Average power requirements in watts. 

b. Peak power requirements and duration. 

c. Voltage requirements. 

d. Noise and transient limitations on the power system. 

e. Experiment data requirements to include films, mag- 
netic tape, specimens, telemetry, video, etc. 

f. Communication requirements to include frequency, modu- 
lation, bandwidths, antenna, time of transmittal, etc. 

g. Environmental requirements to include temperature, gas, 
relative humidity, vibration, acoustics, acceleration, pres- 
sure, etc., as well as the variations during different flight 
phases . 

h. Effects of the experiments themselves on the environment. 

i. Time requirements on ground (or flight) crews. 
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j. Physical requirements such as weight, volume, lo- 
cation, etc. 

k. Spacecraft orientation requirements or special view- 
ing requirements. 

l. Computer requirements. 

m. Magnetic requirements. 

n. Contamination requirements. 

o. Any other special requirements (i.e., 0 "g” environ- 
ment, hard vacuum* snyoptic orbital requirement or any other). 

As you can see the world of independent experiments is a 
complete problem of its own. Couple this with NASA's policy 
of preserving the integrity of each investigation, encourag- 
ing the participation of the best qualified scientists, and 
making the results of investigations available to the scientific 
community at the earliest practicable time (see NASA Policy 

Directive 8030.3) and you have an endeavor that will require 

29 

a major effort from you. You should start this work with good 
people, well placed in your organization. You also need to 
look into the many and varied interfaces to be sure they are 
all open and working. 
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CHAPTER VII 


OTHER IMPORTANT DECISIONS 
1. Human Relations 

In discussing problems and decisions that a NASA manager 
is likely to be confronted with, it may seem unusual to start 
with a subject like Human Relations. However, it is here for 
two main reasons. One, since you as a manager must work through 
people, it becomes necessary to start thinking in terms of 
people. Two, since formal management instruction emphasizes 
behavioral approaches more and more, you are even more likely 
to be exposed to a need for understanding these methods. 

First a word about behavioral management. You should at 
least be familiar with the terms and the approaches. Since 
that cannot be covered here, it would be worthwhile to take a 
short course, glance through a text or read one of the articles 
now appearing in the engineering journals. Suffice it to say 
here that it is a management science dealing with human be- 
havior and particularly stressed by the psychologists, 
sociologists, and anthropologists. It stresses such areas as 
perception, motivation, stress, learning, and decision making. 

A human relations area closer to you at the moment is 
your getting the best effort from those closely involved with 
your project. It is worth some time to think of how you want 
to work with your people and also those at all organizational 
interfaces. The approach one should take is an individual 
thing, depending on your own personality and techniques. The 
important thing is that you develop an approach to handling 
people and implement it. Don’t be passive. 
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if you are authoritarian - a strict disciplinarian and a 

stickler lor seeing that your instructions are carried out, 
you can make that approach work - with fairness, reasonable- 
ness, and a successful project. If your concern is for people 
you can have a very successful project by motivating everyone 
to extra effort. The important thing is to have an approach 
and work at it. Don’t depend on just having a personality 
which somehow takes over. 

It is suggested you think out how much time you want to 
spend with different levels of personnel. You should consider 
ahead of time how you want to handle mistakes. Have you planned 
for the administration and environment of your employees? 

Behavioral scientists are working intently on some of the 
essentials of management - communication, innovation, leader- 
ship, feedback and involvement. It is evident that we will 
feel the effects of these efforts in management, and more so 
every year. A man’s need to belong and the rise of group 
activity in unions and elsewhere will make this approach con- 
tinue to progress. Today, however, it is not likely that you 
need to revolutionize your approach to management just because 
participative methods are on the rise. You do need to recog- 
nize that the days of the entrepreneur and the iron fist rule 
are becoming less and less. A little awareness of this and a 
little thought on how to make your organization feel involved 
is more and more worthwhile. The least you need to do is find 
a way of getting a personal understanding of the feelings of 
people at all levels. 

2. Project Contractor Relations 

While we are on the general subject of relationships, one 
should think of what sort of relationship is desirable between 
a NASA project office and a prime contractor. Again, it is a 
subject you should not let ’’just happen.” Your relationship 
should be deliberate and planned - thought-out by you to make 
the project run according to your own style. What then are the 
issues that you should consider? 
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For one thing, the project cannot depend on formal com- 
munications alone. The project cannot survive if you deal 
with the contractors only through the contract, through con- 
tractual letters and through reports. You must also have 
meetings, face-to-face discussions and other informal ways 
of penetrating the project. You have to dig beneath the sur- 
face to find out what really goes on. This would say you 
really need to see him in one way or another every few days. 

This alone is no doubt a true statement, but there is also 
another side of the problem. 

Can you interface with the contractor too frequently? The 
answer is probably ’’yes.” For one thing you must certainly 
consider ethical problems - either actual or implied. Ethics 
is concerned with the world of values in human conduct and 
the right or wrong is highly subjective. You must answer if 
it is truth and fair and beneficial to all. No standards of 
conduct will be proposed here. But remember, as leader of 
your project, your example is closely watched and easily mis- 
construed. You should think out the example you want to set 
in relations with your own employees, with NASA management, 
and with your contractors. In so doing, remember too that 
you have acquired power. Power and ethics are not by nature 
homogeneous . 

Back to relations with the contractor. If you spend too 
much time together you will at least face having your pro- 
fessional accountancy questioned. If its above reproach you 
can survive that. More important, however, is what actually 
occurs. Since you are frequently called on to defend your 
budget, your schedules, and the adequacy of your project to 
higher headquarters, you will find additional ’'cushion" in 
this area a comforting thing. This causes your aims and goals 
to be remarkably similar to that of the contractor. There is 
at least a danger here. It is the experience of this writer 
that when this situation couples with a too frequent interface, 
it tends to be most difficult to maintain a separate perspective. 
Although a close working relationship with your contractor is 
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desirable, it is neither to your advantage nor the contractors 
to have you identified to a higher authority merely as a 
spokesman of the contractor. Many project managers have been 
so identified in the past. 

How does one maintain both optimums? This is a fair 
question because you can have too close and too loose a relation- 
ship. Of course, you must watch closely the social side. Even 
if you stay within guidelines, if any, this is easily overdone. 
Try not to socialize alone, but let dinners and parties be 
mixed affairs, if possible representing several offices. As 
to the business side, try to stay in a reviewer status. Other- 
wise, if you have a dirty hands all night working session with 
your contractor, for instance, your spirit is to be commended, 
but some objectivity will be lost. Possibly, your staff or 
even line managers should do the contact work and you review 
it. Also, if your project has several pieces of hardware with 
different line managers for each, stress your interface with 
your own managers and interface somewhat less with the contractor 
involved. 

Having been negative enough to provide the above cautions, 
it is necessary to again stress the need for a close working 
arrangement. You should have frequent reviews where you and 
your staff hears the contractor^ viewpoint directly. You 
should visit his plant and he your Center for reviews. He 
should be invited to appropriate reviews even if he is not 
directly participating. This relationship is a personal 
and undefined science. Think out ahead how you want your re- 
lationship to work and how you want it to look. 

3. Problem Resolution System 

This is closely related to your Configuration Control 

System. In fact, if you have gone so far as to implement a 

configuration management system, such as NHB 8040.2, it may 

20 

seem you have covered the method of resolving problems. In 
general, you have. Such systems are built around technical 
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changes. Since these relate directly to cost and schedule most 
of the decisions you are concerned with should come to you via 
the change boards. 

One potential problem here is that you become so ’’wrapped 
up” in change boards as THE problem area that you may overlook 
the fact that other problems may exist. Have you thought about 
how you want to handle problems which do not come before the 
change control boards? Have you thought about what kind of 
problems you want to see and how you want the ones you don’t 
see handled? Invariably, if you just let this situation happen 
you will be making lower level decisions in one area and possi- 
bly none in another. Without guidance your secretary and your 
staff may not approach it the way you desire. In fact, norm- 
ally, they will see if you make certain decisions in some area 
and then, if you do, send you all such decisions. This may 
perpetuate a bad thing. As in most areas you do not need to 
do the staff work personally, leading to a decision. Have your 
staff list all of the decision areas they can with a recommenda- 
tion as to the decision level for each item. 

This again is an area you need to think out ahead of time. 
You need some kind of system. Presumably, from the earlier 
chapters, you have thought about decentralization as well as 
line and staff arrangements. You ought to be in a position to 
know what level of decision you want your line and staff to 
make. Because there are always exceptions and implications, it 
is sometimes difficult to put such rules in an administrative 
procedures manual. Although rules on decision levels can sel- 
dom be fully understood when written, the "first cut” should 
be in writing. It will then be necessary to discuss decisions 
making in a staff meeting. After examples and questions, your 
organization should begin to understand what you have in mind 
even though it is a most difficult area to describe . 

Now how do you want to go about having everyone understand 
your approach to organizational decision making in the same 
way? It is suggested that you construct, or have constructed, 
a decision hierarchy, with yourself at the top, your deputies 
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or direct assistants next, and then your line and staff 
organizations as appropriate. To give everyone a feel, list 
examples of typical decisions for each level. For instance, 
in the area of personnel you might decide that one of your 
offices could reassign someone within their own office by mere- 
ly coordinating with your administrative office. If they want 
to trade a man for another, within your project office, where 
everyone agrees, you may want your deputy to agree. You may 
want your deputy to be informed and approve any transfers in or 
out of your organizations. For technical approaches, you may 
just want a note telling you that your line organization is 
taking an approach which someone in the technical organization 
of the Center disagrees with. Whereas, if the Laboratory Chief 
disagrees you may want the approach coordinated with you before 
it is implemented. 

If a little time is taken to list the approaches to several 
diverse areas, your organization will certainly understand 
your approach. It is vital that everyone does understand and 
work to the same system. If you are unsure how you want the 
decisions made in certain areas, you can of course inform every- 
one that the approach is tentative. You can also arrange to 
have your secretary keep a list of decisions made elsewhere so 
you can check for a while to see if you are satisfied. In the 
midst of the Apollo Program, the Program Director once delegated 
a large amount of signature authority, hence decision authority, 
to his deputy. He satisfied himself on the actions taken merely 
by glancing over a list of items signed in his name. If he felt 
the need to modify any action taken, he was thus informed in 
such a timely manner that modifications were not disruptive if 
they were ever required. Where a number of people have signa- 
ture authority, as in the Pentagon, often each keeps a log so 
that anyone can check what has been signed. 

4. Control vs Innovation 

Those of you who have been exposed to university or other 
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prepared courses certainly recognize control as one of the man- 
agomenl; functions and have probably been exposed to concepts 
of i nno va I. i on . More and more; formal instruction has tended to 
stress innovation. Control implies restraint. Innovation is 
the generation and acceptance of new ideas, processes, etc. It, 
therefore, implies the capacity to change or adapt. The two 
considerations are not entirely homogeneous and hint of some 
conflict. Since the days of Henri Fayol in the early 1900’s, 
it has been recognized that management, particularly project 
management, must have measurable control. Recently, particularly 
with our rapidly advancing technology, the need to innovate has 
become apparent. Can you do both? 

Yes, one can control and innovate. Since both embody an 
attitude, it is not easy for an organization to carry opposing 
views to all levels - but possible. You are the key. You have 
to wear the two hats conspicuously. Perhaps one should think 
of this dilemma in terms of the organization. When one thinks 
of control, one thinks of a tight or bureaucratic organization. 
Most project organizations fits this to a degree. When one 
thinks of an innovative organization one thinks of a loose, 
participative type organization where everyone freely expresses 
various views. It is not easy for you to have both in one. 

The following suggestions may help. Usually each organiza- 
tion has an element through which it monitors the control 
function. For instance, if you have a Project Control Office 
that tracks funds and schedules and also has the configuration 
management function, this is no doubt your control organiza- 
tion. Your interface to that organization has to be one of 
control emphasis. It is here you emphasize tight control, re- 
stricted budgets and closely held schedules. The direction 
through your organization to the contractor will also emphasize 
control. Changes to the technical approach, new ways to ad- 
vance the state-of-the-art, new ways to achieve the goals of 
the project are not compatible with this tight control. You 
have to wear this control hat, however, to succeed in your 
project . 
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There is another side, however, particularly for high 
technology projects. Are we sufficiently abreast of the state- 
of-the-art to warrant the NASA development we are embarked on? 
The objections of Center Management, at times, to Project Man- 
agement is that it must become so involved with control that it 
doesn’t see the future, doesn’t look at the big picture, doesn’t 
properly utilize the Center’s technical organization. You must 
be prepared for innovation. You may need to innovate at any 
time, so you should lay some groundwork. 

There is no way you can do a good job of Project Management 
and not stay largely control oriented. Therefore, to cover 
the innovative view, you may have to take some steps just for 
that purpose. Some suggestions might include: encourage a 

segment of your engineering organization to make innovative 
approaches and suggestions even if few of them can be adopted; 
even if funds are insufficient for backup hardware approaches. 
Using a small amount of funds, encourage backup preliminary 
designs; meet with the Center engineering organization occasion- 
ally to "hear out" innovative approaches; reward by publicity 
or NASA awards the better and more innovative approaches; en- 
courage innovation in other than technical areas throughout your 
project office. Have one or more offices that you particularly 
push for innovation, such as a Systems Engineering Office. 

You must wear both hats so they do not conflict. 

5. In-House Control 

Not all of you will have this problem and there will be 
various degrees of control required. In fact, some of you may 
be seeking in-house involvement instead of worrying about con- 
trol. This is obviously addressed to those who already have ma- 
jor in-house participation. Since it is the normal pattern of 
NASA Centers to play an active Center role in major projects 
under their cognizance, these comments should apply to the 
majority of cases. 

In the first place, if control connotes to you a need to 
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suppress or stifle in-house activity, it is not so intended. A 
good Project Manager will welcome all of the help he can get. 
Ordinarily it is not possible to put in the project office all 
of the people needed to do the job. You have essentially three 
ways you can go. You can use the people you have and make the 
best judgment possible on each decision. You can rely more heavi 
ly on the prime contractor, or you can muster ?. major in-house 
effort to give depth to your decisions. The first two methods 
are generally used by the Department of Defense, with a few 
exceptions. NASA utilizes the third method frequently. Nothing 
is more comforting to a harrassed project manager than to have 
available the depth needed in procurement, legal matters, ad- 
ministration, or technical problems. It is your duty - and 
responsibility - to see that you have your Center depth com- 
mitted to your project, in the amount you need. You can accom- 
plish this by Center agreements, by matrix organizations, by 
working groups, by established contact points, by a subsystem 
engineering approach, by specialized assignments, by task forces, 
or by charisma. In any case, you must see that you have this 
suport as you need it. 

Why then do we head the topic In-House Contro 1 ? It is 
assumed you will find the way to get the help you need. All of 
NASA is dedicated to that approach. You then need to think of 
keeping that help in perspective. Legal and administrative 
assistance is seldom a control problem. Procurement help may 
or may not be. So much of the management of a prime contractor 
is procurement connected that you should give that area some 
thought. It is important that you obtain all of the help in 
that important area that you can. The locations of various 
procurement offices may be widely dispersed and hence require 
more trained personnel than you would expect to have. Unlike 
technical matters the procurement recommendations are usually 
things you can agree with provided they fit your general policy. 
Therefore, the main thing is to have the necessary elements of 
control. Either by co-location or by organizational assignments 
you can expect to influence procurement matters. Procurement 
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is one of the essential elements of Project Management; you 
should not be expected to manage without it. 

The most difficult area of in-house control is probably 
technical control. This area is so widespread you cannot ex- 
pect to have all involved technical people assigned to you. You 
should not even expect all such personnel to be subject to your 
direction. You are looking to them for technical integrity 
and you are seeking responsiveness to you. You will have more 
differences here than anywhere for several good reasons. One, 
all Center Directors are technical men and expect the project 
to achieve its technical goals. They will take personal interest 
in the technical progress and naturally will want to hear from 
all elements of the Center. You will exercise project control 
more in the technical area than any other because of the effects 
on costs and schedules. Such controls are repressive to someone 
trying to improve the project. After one is turned down a 
number of times, it is natural to try any channel for the changes 
one believes in. Also, the in-house technical organizations, 
getting involved more and more, and with no more people, will 
tend to cut corners where a contractor may not. This affects 
the formal drawings, the documentation, the quality control of 
government furnished items, and so on. 

Therefore, in the technical areas you must watch for, and 
control, many things done in-house. You will be concerned with 
Center approval of technical proposals that you have turned down 
only because of insufficient funds. You will find strong sup- 
port to add tests that will disturb your schedules. You will 
find a tendency to short cut in-house drawings, reports and 
quality. This must not happen. The Contractor and the Center 
organization must be treated alike - have the same type of 
responsibility . 

How do you do this? Put yourself in the place of Center per- 
sonnel trying to do their job. First, don't call them project 
"support" personnel. Take the necessary steps to "make them 
belong." Take time to hear their side. Occasionally invest 
a little, even if you don't see the need. You must have their 
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help to know when a contractor proposed change is necessary. 

Spend a little time and money then in protecting your invest- 
ment. Review in-house work in the same manner as contractor 
work . 

6. Subcontractor Control 

A reason for mentioning subcontracts at all is that there 
is so little coverage of the subject anywhere in NASA documenta- 
tion. If one is concerned about a related subject, control of 
government furnished equipment, there are procedures set up for 
controlling these items. For instance, 533 M, Q & P (Monthly, 
Quarterly and Performance) forms are set up for contracts from 
$100,000 to $500,000 and most Centers have procedures to assist 
in setting up such control. If you are concerned with a prime 
contractor's handling of subcontracts, however, very little has 
been written. RFP's for instance, usually just point out that 
subcontracting is the responsibility of the prime contractor 
and that make-or-buy plans involved are subject to later approval 
or revision by the government. At least one Center has drafted 
criteria for subcontracting, but since this is one layer 
from the prime contract, it is difficult to attempt to control. 

This apparently says that NASA management has fully dele- 
gated subcontractor management to the prime contractor. In a 
sense, of course, this is your intent. Certainly, you want the 
prime contractor to feel responsible for his own subcontracts. 
However, as you know, a high percentage of technical, schedule 
and budget problems take place in subcontracts. More quality, 
reliability and test problems probably result from products ob- 
tained by subcontracts than by the work done directly by the 
primes. You cannot be just an observer on subcontracted parts. 

A great part of your total time eventually will be spent in this 
area. It is not logical to leave the subcontract area alone 
until it is in trouble and then become wholly involved. 

What then is the right answer? First, it is a proper start 
to write the RFP so that the prime contractors are responsible 
for their subcontracts. However, it is suggested that the RFP 
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either contain some policy guidelines or refer to such a poli- 
cy document. This is often done but usually not to a sufficient 
extent. Some Centers have documents concerning subcontracting 
which can be very useful. 

The real answer, if you start it in sufficient time so as 
to have it ready, is to have your organization produce a plan- 
ning document on subcontracting. In it you should covet all of 
the disciplines interested in subcontracting and state your plan 
for how you desire to have subcontracting handled. Recognizing 
it is still the prime contractor's job you are interested in, 
stating minimum and in some cases, maximum boundary conditions. 
For instance, for which items do you want certain engineering 
safeguards, such as specifications that would not ordinarily be 
covered, by having certain items produced on government or prime 
contractor drawing format, etc.? For quality, are there items 
where you need to have a government or prime contractor quality 
man cover the subcontractor's plant? Do you want subcontractor 
traceability or use of high-reliable parts specified anywhere? 
Concerning tests, are acceptance tests sufficient to prevent 
holdup of major tests later on or do you need to specify certain 
development or quality tests? 

It is not possible to give all of the subcontracted parts 
the consideration described above, nor should you. However, if 
you describe areas where these special features must be con- 
sidered, you will have taken a major step. Such considerations 
could cover where the state-of-the-art is being advanced signi- 
ficantly, where vibration or acoustic conditions are severe or 
where past experience gives cause for concern. 

One obvious feature of this effort is that you will draw 
the prime contractor's attention to subcontracting - at an ear- 
ly phase in the project. This alone may be worth the effort. 
However, in addition, some real attention to detail here, by 
your staff, should catch some major potential problems. No 
major space project yet has flown without an inordinate amount 
of time spent trying to sort out some feature of subcontracting. 
This is usually made more difficult by the fact that trace- 
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ability or inspection, or whatever the problem, was done dif- 
ferently for the various subcontracted parts. 

If you want to go a little further here are some features 
you can consider. During negotiations, review the contractor’s 
internal procurement system against his system description and 
against some of the following criteria. Does he provide a focal 
point for planning and managing the procurement system? Does 
he define individuals and interfaces for his system? Is there 
a clear relationship of procurement with project management? 

Is there an identified procurement interface with other company 
divisions and subsidiaries? Are there procedures for initiating 
and following up procurment awards? Are there procedures to 
insure competitive awards? Is surveillance established for 
awarded contracts? Are subcontractors measured in areas of 
costs, schedules and performance? Is there a procedure for re- 
solving problems and making changes? Are the data requirements 
described? Even though you may not want to prescribe criteria 
in all areas, a look at such criteria and some probing questions 
are in order. 

7. Specifications 

Specifications are a major concern to you and a major cost 
item. It is easy to say that you should give specifications 
early attention, but it is difficult to say just what you should 
do. Specifications are somewhat like documentation, but are 
more difficult. In both cases all of the specialists want to 
have as much as possible in their particular area. 

The usual situation for specifications is that too many 
are imposed. The contractor will have engineers go over all 
of the specifications you list and study them. This takes fund- 
ing. He will also implement all of them. This takes funding 
too. In both cases the amount probably could have been reduced. 

There are three major reasons why the number of specifica- 
tions imposed on contracts are excessive. One is that they are 
so discipline-oriented that specialists are permitted to impose 
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them in each area. Two, they are so numerous and unwieldy 
that they are not "combed" often enough to see if they can be 
reduced. And three, too often when a specification is imposed 
because some part of it is desired, the whole specification is 
listed instead of just the part desired. 

Near the end of the Apollo program, the major aerospace 
contractors of that program were surveyed to see how costs of 
future space programs could be reduced. Although they were 
contacted individually each one listed excessive specifications 
as a major cost item where major reductions could be made. Al- 
though the treatment of specifications was not uniform most of 
the aerospace contractors studied the specifications in depth 
and imposed them thoroughly and carefully. 

The best way to restudy the status of specifications is at 
the Center level. Specifications usually represent Center poli- 
cy, they are applied to all Center projects and their study is 
time consuming and involves many people. Of course, it is better 
if you restudy the specifications before you negotiate a con- 
tract, but it is not too late even if the contract is under way. 
Therefore, if the specifications used by the Center have not 
been reviewed recently, perhaps you can persuade the Center to 
make such a study. Another method is to ask the contractor to 
suggest all specifications he considers too costly and perhaps 
unnecessary and then have your office or Center personnel re- 
view just that list. Another approach is to appoint a small 
task force to study the specifications in a few of the disci- 
plines to see if there is a problem. Lastly, of course, you 
can ask your own discipline oriented staff to review the 
specifications in their own area; however, this approach is 
generally less satisfactory. 

As in most areas, the fact that you are interested in this 
subject will have a rewarding effect. Government and industry 
personnel will then take an interest in the project specifica- 
tions and surface some of the problems. This discussion has 
been oriented to the situation where the specifications imposed 
are too numerous. In general, this is the case. Hopefully, 
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however, any review will uncover important omissions also. 

8. Make-or-Buy Criteria 

The make-or-buy planning is mentioned here in order to 
bring it to your attention early. The standard RFP "boilerplate 
will require that the contractor submit his make-or-buy plan to 
the government, and it will also inform him that the government 
may require revisions to his plan. Often that is all that is 
said on the subject and generally you will be so busy that you 
won't even think of make-or-buy considerations until much later. 

In general, after insuring that the contractor uses 
standard GFE items wherever possible, the breakdown of "make- 
or-buy" is left to the contractor. However, there are considera 
tions which may cause government interest in the plan. Some- 
times, the lack of early consideration of the make-or-buy plan 
causes problems later. You may be concerned about the con- 
tractor’s ability in some area and desire that he have certain 
work done out-of-house. You may be concerned about the per- 
centage of work that he does in-house. Small business considera 
tions may cause you to want to increase the efforts in those 
areas. You may have critical parts that you want the prime 
contractor to design and build himself. The prime contractor 
may be improving the corporation role by placing major work in 
other corporate locations by Interdepartmental Work Authoriza- 
tion (IDWA) when you are concerned over their ability to produce 
You may have any number of other special considerations which 
will affect how the make-or-buy plan is constructed. 

There are any number of ways you can explore, or have ex- 
plored for you, the make-or-buy considerations for your project. 
Assuming it is not the sort of thing you want to put a great 
deal of time on, a suggested approach is a short brain-storming 
session. You can lead, or you can have led, a session with a 
small select group of personnel from your office or throughout 
the Center. You are simply interested in any items that affect 
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the make-or-buy plans for your project. 

It may help you in assessing "make-or-buy" to review 
briefly how the contractor approaches the subject. The make- 
or-buy plan includes major components, assemblies, items 
adding up to a large dollar value, data, or services. To the 
contractor it is divided into two parts - the plan required by 
the contract to be submitted to the government and a plan for 
all other items required. The contractor realizes the customer 
is interested in using standard GFE, using existing sources, 
maintaining true source competition and having a broad distri- 
bution of procurement. He, in addition, is interested in his 
competitive position, in maintaining a labor base, in preserv- 
ing technical skills and in balancing his capital investment 
program. 

Ahead of time he will have a general preplan, broken down 
by such headings as: solar arrays, batteries, inverters, regula- 

tors, cabling, computing and sequencing, auto pilot, inertial 
reference, and so on through all possible subsystems. These 
will be listed as "make" or "buy" or possibly "to develop a 
capability." Unless some of the considerations in the above 
paragraph prevail, he knows in general what he should make or 
buy. However, since a company's viability and future growth 
are strongly influenced by its capability to design and pro- 
duce internally those elements which represent the bulk of its 
sales, you should expect a strong interest in doing work in- 
house. 

9. Costs Not Directly Related to the Project 

All revenue sources for the Center, such as your project, 
are subject to outside "taxes" or at least requests for sup- 
port. These include such items as TU (Technology Utilization), 
support of advertising activities of the Public Affairs Office, 
furnishing Project hardware to museums, etc., and Center basic 
and supporting research programs. One should not automatically 
subscribe to all of these items nor should one adopt the atti- 
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tude that all such requests are unreasonable since your pro- 
ject is underfunded anyway. 

Probably the wrong way to handle such items is to just let 
them happen and settle each as it occurs. If you just had a 
budget review you would probably turn down any item requested 
that day, and if you had a good test you might approve the next 
request. One good approach is to develop your own basic poli- 
cy to all such items and then appoint someone in your office, 
part time, to handle all such items within the policy. This 
works best when the person designated is from your immediate 
office, such as an "assistant to" or "executive assistant." 

He should list at the beginning how many such items you expect 
to affect your project and then treat each one within your 
policy. This should result in recommendations back to you which 
will permit planning early in the life of the project. It 
should also cause all offices affected to realize that they were 
treated fairly compared to others and within a planned policy. 

A related item , somewhat in reverse, is the contractor's 
use of IR&D funds. Do you have advanced state-of-the-art 
developments in your project where he might be persuaded to 
apply his IR&D funds? This could apply in particular to portions 
of your project where the contracts are not yet determined or 
negotiated. 

10. Parts Lists 

There are a number of parts lists involved in NASA develop- 
ments. These include "Hi-Rel" (High Reliability) parts, quali- 
fied parts lists, standardized parts lists, previously developed 
parts list, and even previously proven subsystems. You should 
think out your approach to these various lists. Some, like the 
"Hi-Rel," can be expensive to use if we over specify such parts 
for all uses. Most of the other lists have been compiled with 
a cost savings in mind. It is good business to utilize quali- 
fied parts, where possible, instead of redesigning and requali- 
fying new parts of each requirement. The usual comment by design 
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engineers is that "such and such" an approach would be better. 
This is usually true. However, in these days of less funding 
and greater experience, you must ask yourself if the better ap- 
proach is necessary. Considerable savings can be realized by 
restricting "hi-rel" parts use, and by using all qualified 
parts (or subsystems) which will satisfy your requirements - 
even if they aren’t the best. Many parts are selected because 
of the requirements in the reliability section of the perform- 
ance specification, so whatever you do starts there. 

Probably you will want to establish your own policy first. 
Most Centers have policies in these areas, so these need to 
be checked first. Once you have an overall policy you will 
need to make your contractor aware of it. Since costs are 
affected this should really be done in the RFP and part I of 
the specifications. This is particularly true if your approach 
is a significant departure from the approach the contractor 
would be expected to take. For any refinements after the RFP, 
it is a good approach to give the contractor your views in a 
letter, telling him why you have taken this approach and sug- 
gest it to him without directing it. This general approach to 
contractor direction is recommended in many areas and can save 
money on directed changes. With an official letter he must give 
the suggestion serious thought. 

The last thing you have to insure is that your own project 
office and the Center engineering, quality, etc., groups under- 
stand the approach on parts. These groups not only may be work- 
ing in a different direction, they have considerable influence 
at various contractor levels. Certainly the contractor should 
not feel the influence of more than one policy. 

Most of the contractors have complete guidelines for parts 
programs and for preparing preferred parts lists since NASA 
projects are all low- volume, high-reliability projects. They 
can go as far as your reliability and performance specifications 
dictate. Since electrical parts alone on a large project 
will number over a hundred thousand parts, you must go far 
enough, and not too far. The contractors will impose controls 


144 



on design, incoming parts, fabrication, and subcontracting. 

A good program trades off schedules, mission profiles, environ- 
mental conditions, and cost of implementing and maintaining 
the program. They must consider such items as preferred parts 
lists, parts specification, quality assurance, parts surveil- 
lance inspection, failure analyses, handling, stocking, vendor 
monitoring, and screening. You will want to be sure that once 
you have set all of that machinery in motion, it is to the 
proper depth. 

The Air Force encourages use of a QPL (qualified parts 
list) by eliminating many requirements for identification, for 
FACI, for test reports, and for other reports. This program is 
successful and their qualified parts are used to avoid new 
development. In March 1964 NASA studied the problem with a 
view to certralizing these activities, standardizing terminology 
and participating with other agencies. The DOD-NASA programs 
which resulted from this included IDEP on data exchange and 
FARADA on failure rates. Electronic Component Research Center 
(EGRC) , Batelle 1 s electronic parts program was also studied by 
NASA. These show the need and NASA interest in improving NASA's 
use of parts lists, but these efforts were too bulky, time con- 
suming and hard to keep up to date to impose in contracts. 

NASA continued to recognize the need to utilize proven parts for 
expected conditions. 

One last related item is commonality. This is a simple 
word, but it can involve everything from using the same transist- 
ors throughout the project to using the same booster for re- 
lated projects. The advantages of a commonality program range 
beyond development cost savings. They include reduced stock of 
spare parts, less training required, simpler maintenance, fewer 
interfaces, etc. It is worthy of your consideration. 

11. Packaging and Transporting 


Obviously this is not as large an item as some we have 
discussed. It was an item of greater impact in the Armed Forces 
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where large quantities of items were packed, preserved, shipped 
long distance and subjected to a difficult environment. Be- 
cause NASA has a lesser problem, we sometimes fail to give it 
sufficient thought. 

You need to think out ahead of time the major transporta- 
tion routes of the larger items to be shipped. If accomplished 
early much can be done. You can arrange rerouting. You can 
ship before some part is assembled if it causes removal of 
poles, lines, etc. You can sometimes make some redesign if 
your present design doesn't fit the better form of transportation, 
i.e., the Guppy, truck vans, railcars, etc. Sometimes a little 
different arrangement in what is to be assembled at the test or 
launch site can cause major savings in shipping requirements. 

Packaging can present a similar situation. If not pre- 
planned the status of the project hardware can require elabor- 
ate containers having shock conditioning, temperature and hu- 
midity control, pressurization capability and so on. In some 
cases the whole transporter, such as the Guppy, may have to have 
these severe environmental capabilities. 

The essence of the above is that the criticality of the 
design of your project and the limitations on time can easily 
force you into situations where you pay an excessive price for 
shipping. One feature that sometimes complicates this situa- 
tion is the contract itself. From a sheer manpower point of 
view most design considerations are initiated by the contractor. 
Many NASA contracts are written so that the government has major 
transportation responsibilities. These situations make it 
particularly incumbent upon you to initiate the proper action in 
a timely manner. 

There are many ways you can initiate a proper action. One 
good way would be to have your staff office which is concerned 
with logistics, initiate a survey of the entire transportation 
area. To be effective this must be accomplished in time to 
influence the contractor's preliminary design. Along with the 
survey you should require your logistics office to develop a 
transportation plan. Thus they would study the project, obtain 
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a preliminary feel for size, weight and environmental conditions 
and begin to develop a plan for the best way to transport the 
necessary items. If this is started in time proper trade offs 
between design and transportation can be made as the design 
progresses. Your staff would have to involve the contractor’s, 
thus getting them to think about the problems at an early date. 

12. What Level to Track and Control 

The next several subheadings involve control. Much of 
your job as a manager involves control. It is a subject that 
all management textbook writers devote considerable attention 
to. As portrayed there you write a good plan and you control 
to the plan. This is true. There are some other features of 
control that should be mentioned, however. 

As described in formal instruction, a good plan stimulates 
good control. Also, a good management information system, as 
discussed in Chapter IV, contributes greatly to proper control. 
One of the things that occurs if the above items are not 
handled carefully is uneven tracking and control. You will find 
sometimes that you are tracking one piece of hardware to a 
lower level than another or that you are tracking quality tests 
lower than development test or other such inequities. More 
aggressive staff or line managers can further contribute to un- 
balanced tracking and control. 

There are other features that help determine the depth of 
tracking and control. The type of contract and the responsi- 
bility given to the contractor have a great deal to do with the 
depth of tracking and control. How you are organized and back- 
ed up by the Center organization affects your approach. You 
do not want more information to see or controls to manage than 
you have organization to apply to it. 

Another consideration is what is critical to your particu- 
lar project. It is quite possible that you know at the begin- 
ning that schedules or a piece of hardware or a particular test 
will have problems and you want your depth there to be in more 
detail than elsewhere. 
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All of this must be satisfied by your method of control. 

Say les and Chandler in their "Managing Large Systems” which 
is a text based on their observations of NASA management, state 
the following, "Control systems designed to encourage excellence 
of performance are a key management tool.” "What kind of ex- 
cellence-inducing control system does the multiorganization 
want to develop? What should be the major sources of control 
over organizations participating in the program.” "One thing 
is certain, the managerial control solution cannot be a simple 
one.” "A top manager of a large-scale system is continuously 
seeking a means of identifying problems as they first arise. 

To achieve this goal a pressure system must be devised that 
will correct significant errors and prevent major distortions 
from arising.” 

This view from one text was stated here so as to emphasize 
both the importance of control and the importance of controlling 
properly. Few managers can accomplish all features of manage- 
ment properly, but the work should be done so that the control 
function operates by itself - or enough so - that you, the mana- 
ger, can focus on other forward looking aspects of the task. 

This includes many things. It means your management information 
system must function, and we will come back to that. It means 
your change control must be thorough and smooth. It means your 
organization must run smoothly, as a team and with esprit. It 
also means your relations with your contractor must be on a 
sound basis. 

If the above exists, and partly to help it exist, you must 
think about your controls early. How much control is mechanized 
and how much is by people? How deep do you want to control and 
where do you want to control deeper? What system of reviews 
must check the control you desire? How do you want status and 
variation reported? One suggestion; insofar as you feel you 
are well organized, do not have your controls set too deep. 

Don’t have you and your staff inundated with paper and reports. 
Give the contractor and your staff room to operate. On the 
other hand, by either personal means or a well designed manage- 
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ment information system, occasionally explore an item in 
great depth. This lets you understand organizations and 
the status of your project in some detail. It also keeps 
all organizations "on their toes" if they know you, the 
manager, may pursue any problem or activity in fine detail. 

13. Weight, Performance and Schedule Control 

The items listed in this subject probably don't even 
have to be mentioned. They are the heart of any NASA pro- 
ject. Except for costs which will be discussed later, if 
weight, performance and schedule are under control, the 
project is probably under control. The purpose of listing 
these now is to let you think of these items collectively 
for a moment and be sure that they are all considered and 
in context. A good way to maintain the monitoring of these 
items is by trend analysis. 

Weight and performance tend to work against each other. 

To increase your performance you will probably need more 
weight. To take weight out of your project you will find it 
difficult to do without affecting the peformance. The se- 
quel to this comment is that if you have a weight problem, 
but no problem with performance, or vice versa, you had 
better think of both variables from the beginning. If one 
of them is in trouble, it is probable that the other eventually 
will be affected. 

In measuring overall performance today, we tend to use 
the Work Breakdown Structure. With the whole project divided 
into small measurable tasks, it is easy to lose sight of a 
weight problem or a performance problem as we use it here. 
Concerning performance, if you are building something like a 
rocket engine the resultant performance is so much a part of 
the end product that it is obvious what you are measuring. 

If you are building a launch vehicle, or a communications 
satellite, or an earth resources satellite, or some other 
advancement to the state-of-the-art, it is true you will have 
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specifications expressing minimum or target requirements for 
such things as range, accuracy, capacity, etc. Invariably, 
however, the need for greater and greater performance increases 
as the development progresses. This can be very disruptive to 
a project in late stages. Also, it will be costly to increase 
performance or decrease weight if they are not accounted for in 
the original contract. 

You should examine your project early, preferably before 
the RFP to see if you believe there is any possibility of a 
problem or an increased requirement in these areas. If there 
is, you need to have weight and performance controls. You will 
probably need to combine these with incentive features in the 
contract. These areas should be reported on and tracked care- 
fully even before there is a problem. 

Schedules also are accounted for in the Work Breakdown 
Structure. Usually there is a very complete treatment of 
schedules. Since schedules are a red flag alert to all kinds 
of problems, they are of particular interest to you. If you 
now track weight and performance specifically and separately, 
you must be sure your schedule tracking alerts you to problems 
or potential problems in these areas. If these new items do 
modify your WBS, it is probably that you also need to add cer- 
tain schedules to your master schedule list. 

14. Computer Control 

This is a somewhat different type of control to discuss 
right after items that are made part of a plan, to track and 
control. The type of control we have in mind here will no 
doubt require tracking, but the control is more in the sense of 
not letting an essential element of a project get out of hand. 

Computers are here to stay, and properly utilized are vital 
to the project. A difficulty with computers is that it is an 
item handled by specialists. As such it is difficult for a 
manager, talking through layers of people to fully understand 
the requirement for computers. Also, there is a natural in- 
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clination of the specialist to need the latest generation of 
computers and to need computers of large size and in large num- 
bers. In addition, a prime contractor may have a tendency to 
a very large computer capacity. If you are tightly controlling 
his manpower and not controlling his computer capacity, he can, 
to a degree, trade manpower for computer time. Both in-house 
and at a contractor plant, each new project can serve as a 
requirement for new computers. 

You do not want to sell yourself short on computers, but 
you need to know what your contract says about computer time, 
preferably before it is written. You need to know what in- 
house capacity you are supporting. You need to know how much 
computer time you really need and what type computers you 
need time on. Used indiscriminately computers are very expensive. 

It is suggested that you have one of your staff develop a 
computer usage plan which answers the above questions. Unless 
you are a computer expert it is suggested you ask for a compari- 
son of computer usage for projects similar to yours. As before, 
an early interest and a few correct early steps taken by you 
will cause everyone to realize you are interested in running 
this aspect of the project in a businesslike manner. 

15. Communications Control 

Unlike some of the previous discussions this particular 
subject is probably as concerned with too little as too much. 

In fact, you are more likely to underplan your communications 
than to overplan them. In this discussion we are not talking 
of the communications links that may be connected with your 
project after launch. We are discussing the communications you 
require with your contractors, with your own remote offices, 
with your supervisors, = and with any others connected with your 
project . 

Usually the types of communications we are discussing are 
not planned. Occasionally when they are, they include several 
telephone lines, TWX circuits, hot line circuits, even televi- 
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sion links - to the extent that they can be overdone and pro- 
hibitively expensive. This is not usually the case. Usually 
a little more thought on improving project communications is 
money well spent. Good communications are a key to a good 
project. From the Office of the President of the United States 
on down there is constant concern that everyone who needs to be 
informed, is informed. Because any communications you install 
may appear to be an added luxury item, there is a tendency to 
consistently underplan project communications. Also since 
telephones and review meetings already exist there is a feeling 
that nothing else is really needed. 

Good communications should be a feature of your good man- 
agement. It is not enough to simply have a means of communica- 
ting if the need arises. The need is constant and one needs to 
have means that facilitate usage. One should not only consider 
communications to your key government and contractor people but 
also should insure that information flows to the many levels 
concerned, that horizontal communications exists, that it flows 
up as well as down. This takes some planning. 

You should have a layout of all who need to have direction 
from you and of the flow onward from each of them. If special 
telephones or TWX's are needed, and the project can possibly 
afford them, then they should be provided. You should determine 
what it takes to facilitate information flow. It seldom hap- 
pens by itself. You should consider what means other than 
mechanized means can assist your communications. These can in- 
clude reports, meeting, oral presentations, verbal direction, 
etc. Do not add means of communications that you do not in- 
tend to use. However, if you use it - so more information 
flows - it is probably worth the cost. 
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16. Failure Investigations 


The next several subheadings will mention a number of 
items which generally are concerned with the time frame after 
development and during testing. They can be brief and serve 
only as reminders. The first of these is failure investigations. 
The need here is to have a system ready. Usually there isn’t 
time after a failure to do all of the investigation planning 
properly if you have not considered it beforehand. 

Your Center or the launch or test site may have pro- 
cedures already in being for major failures. If so, all you 
will have to do is be familiar with them so that you can deter- 
mine ahead of time how your organization may be involved. How- 
ever, such procedures may not exist. In any case, there will 
be a level below which you will want investigations conducted 
where no plans exist. This is particularly true for moderate 
cost items still under contractor control. 

The simplest procedure is to preappoint an investiga- 
tive board, with alternates, and write enough procedures to 
state what they are to do, how to report, etc. If you prefer 
you can just write procedures and enlarge on them enough to 
cover the appointment of the board also. In any case, if you 
become pressed for time you will be glad to have a way to pro- 
ceed all ready when the need arises - for all types of acci- 
dents or failures. 

17. Amount of Flight Data 

Again, it would not seem that you would be surprised 
at considering this item. Decisions on the amount of flight 
data are a normal part of Project Management. Let this just 
remind you to make these determinations in an orderly way. 

Often a stab is taken at just how much flight (or test) data 
is required when early project design is underway. As time 
goes on this is broken down by the system to be used (FM-FM 
telemetry, etc.) and finally continuous and multiplexed chan- 
nels are determined. What is available then is divided among 
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those requesting data. Considering this problem as a system 
problem at the beginning often can help the decision making 
in this area. Is project development telemetry to be traded 
off with project data transmission? Are there new development 
systems that will require more data than other areas? Do you 
have enough telemetry throughout the flight hardware to have 
a good chance of determining a failure in any area? Are you 
transmitting large amounts of data in some areas out of habit 
when the data could be reduced? 

Nothing is worse than having to add to your data system 
at the last minute in order to solve urgent requirements. Major 
rearrangement is nearly as bad. Early system planning for data 
use can do much to solve these problems. 

18. Tracking and Data Acquisition 

Related to the amount of data transmitted is the require- 
ment for tracking and data acquisition. There are five major 
test ranges in the United States and documents are available 
for each describing facilities, procedures, and tracking equip- 
ment. Fitting your project to the range involved can simplify 
your development. If per chance you are not familiar with the 
test range you will be using, you should visit it enough to be 
thoroughly familiar with it. Also, all NASA satellite tracking 
is the responsibility of Goddard Space Flight Center and the 
deep space network is the responsibility of The Jet Propulsion 
Laboratory. Knowing their capabilities and requirements is 
vital. NASA's Office of Tracking and Data Acquisition has 
overall responsibility in these areas. One thing you can con- 
clude from these comments is that if you have very extensive 
tracking data requirements you will be involved with a number 
of interfaces and some different planning and requirements 
documents . 

Three of the most pertinent comments you can consider in 
these areas are; Thoroughly familiarize yourself with the 
people and equipment concerned with your test sites or ranges. 
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Insofar as possible, design your project to fit the equipment 
at the test site or range, since the sponsor of new requirements 
will bear heavy costs. Keep your requirements only to those 
needed, since activating tracking areas or ranges is a high cost 
item . 


19. Planning for Flight Hardware 

You will have put a lot of effort into your flight hard- 
ware. Be sure you protect your investment while the flight 
hardware is being transported and while it is at a launch site. 

It has been mentioned earlier that there are major savings 
possible in designing to the best means of transportation. 

There are savings too in taking care of the completed hardware. 

Some of the obvious concerns are the provision of safeguards 
for the environment, i.e., shock, pressure, temperature, humidity, 
etc. These items must be provided for in transit and while in 
storage or preparation at the launch or test site. As in most 
things, if these provisions are provided hastily when needed 
they are costly and makeshift. Incomplete preparations for any 
aspect of environmental protection can produce serious conse- 
quences . 

An even greater hazard to flight hardware may be the numer- 
ouse interfaces the hardware may encounter. When hardware moves 
it encounters many new interfaces - changes in government or 
contractor organizations for transportation, new receiving 
personnel, new storage personnel, new engineering and quality 
organizations, new test and checkout personnel, etc. This at 
least requires careful planning. If you have a complex project 
and it experiences environmental and interface problems of any 
magnitude, during this period, one suggestion is worth consider- 
ing. It may be worthwhile to assign a project engineer to each 
piece of flight hardware to travel with it. So many unforeseen 
problems can occur that this precaution may save time and 
dollars . 
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20. Launch Vehicle 


The launch vehicle can have many relationships to the devel- 
opment project, from where it is an integral part of a project, 
such as in Apollo, to where it is mass produced by a different 
organization and even launched by an outside agency. When it is 
highly involved with the project, no further comments are 
required. It will be a major part of your total development 
effort. When it is furnished as a standard, proven item, don’t 
take too much for granted. 

Each launch vehicle presents its own gambit of problems. 

You will no doubt have considered its own peculiar environmental 
conditions during launch. It will also have some mechanical and 
electrical interface requirements for the spacecraft which must 
be preplanned. Sometimes a launch vehicle imposes restriction 
on checkout such as on radiation of certain frequencies, launch 
direction, accessibility, gantry availability, control center 
requirements, and so on. One of the biggest considerations is 
that the launch vehicle will determine the exact launch area. 

You will have to adapt to the launch pad and control area that 
fits the particular launch vehicle. 

Many projects set up a launch operation or operations staff 
office. There are so many things such as this and the other 
previous items which they can watch out for, that this may be 
worthwhile. in any event there is planning for someone to do. 

21. Contractor Organizational Phasing 

This series of decision making topics can also be covered 
briefly. These topics are administrative or organizational in 
nature. The first item to consider is the organizational phasing 
of your contractor. The same thoughts probably could apply to 
your own office, but since your personnel are not a major con- 
tract cost item we will address the contractor personnel. 

There are several facts one can start with. The heaviest 
requirement for contractor personnel is early in the project so 
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the contractor organization at the beginning will be complex 
and the staffing heavy. Later in the project schedule, the 
organization should be simplified and the staffing reduced. 

Most contracts rely heavily on cost control, by incentives or 
other methods, and thus depend on costs to reduce manpower as 
required. Manpower is by far the most expensive item in your 
project . 

Contractor manpower phasing may work very well if left to 
incentives and cost control, but it may not. It may not be con- 
venient for a contractor to lay off a large percentage of his 
work force at a particular time for reasons which are peculiar 
to his own situation. For instance, if he is expecting the 
award of a new project which will require in six months the 
manpower now on your project, it may be better business for 
him to retain these personnel on your project, even if some 
incentive fee is lost. This situation may or may not be to 
your best interest or to the government's best interest. 

As in each instance you must think of your early planning 
in this area. However, there are a few thoughts worthy of 
consideration on this subject. It is necessary that you 
track manpower very closely and that you understand even the 
smallest deviations from plan. For instance, a small upturn in 
manpower may be explained to you as just the coincidence of 
many of the contractor personnel returning from vacation at 
one time - or the effect of a five week month. If such is the 
case - fine, but be sure. One, the contractor planning is 
usually too good to miss coincidences such as these and, two, 
if this is not the case your problem will be out of hand by 
the time you get another periodic manpower report. 

Another thought is to be aware of the environment affecting 
your contractor. Is he bidding on several new projects? Is 
his "other business" financially sound now? Is he subject to 
having a project terminated which could dump a number of 
people? A final thought is that you should try to develop the 
relationship with your contractor where perturbations like this, 
without warning, do not occur. It is seldom company policy to 
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keep you in the dark. His only reason for not telling you 
things is his concern that you might stop him from doing what 
he thinks he has to do. If you develop a relationship with 
him that insures fair treatment both ways, you both usually 
profit by avoiding surprises. Frankly, also, if you make an 
honest attempt at such a relationship and if you make it clear 
you will not tolerate such situations you are in a position, 
after one surprise, to see that it doesn't happen again. 

22. Contractor Key Personnel 

An item closely related to the previous item is the under- 
standing you have with the contractor on changes to his key 
personnel. It is inevitable that there will be a number of 
changes in contractor personnel who are critical to your project, 
during the life of the project. You have to be concerned with 
the extent and timing of these changes. 

The best possible answer is to have proposed changes pre- 
sented for your agreement prior to implementation. Then pro- 
posed changes can be negotiated into the contract as prepriced 
options which may be experienced by the government at a later 
date. Unless this is specifically required by the contract, it 
is seldom done. The solution usually tried by a government pro- 
ject manager, after a surprise or two, is to achieve a relation- 
ship with his industry counterpart which prevents surprises. 

This is worth doing, but since everyone knows the situation, it 
is easily circumvented by the company surprising your industry 
counterpart, too. 

Both government and industry have requirements on key 
personnel which sometimes conflict. You require that sufficient, 
capable engineers and managers remain with your project until it 
is properly and economically developed on time. The contractor 
must see that his assets are assigned most effectively to the 
tasks he has to do. However, he does have additional responsi- 
bility regarding existing projects which are working satis- 
factorily. 
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You both need to recognize each others problems. In your 
case you should not be overly demanding in your requirements oi 
him. For instance, it would not be proper to insist on knowing 
oi every personnel change he makes or every shift of personnel. 

One good approach would be to select, say four or five persons 
who you consider vital to the project and request that you be 
notified prior to any planned reassignment. You might do the same 
for any shift of personnel more than some set amount. For other 
changes you could ask to be notified as they are accomplished. 

You note that the above wording said "request." Direction 
is probably not required. Since it is a request it should be 
done in writing, possibly by a contract letter. This will per- 
mit forwarding it to proper company officials. Also as a re- 
quest no one should take issue with it. On the other hand, it 
does not help a company's record and files to ignore it. Experi- 
ence has shown that it will be honored. 

23. Committees 

Any text will tell you that the use of committees is both 
good and bad. Committees are an organizational concept, such 
as line and staff organizations. They can be permanent or 
temporary. The principal advantage of a committee is that it 
permits an interchange of ideas and a judicious deliberation on 
problems too broad or too difficult or too important for any 
one individual. The disadvantages include the diffusion of re- 
sponsibility, the fact the decision process is common to all 
members and, hence, maybe not the best, and the fact committees 
can delay and suppress any action. 

If committees are used to avoid making a personal decision, 
obviously they are not an asset. If one recognizes their strong 
point and limitations and utilizes them properly they can be 
very useful. If not managed they are a costly approach; however 
they permit you to control use of other organizations. They 
let you combine government and contractor thinking. They permit 
bringing great expertise to bear on a problem. An outgrowth of 
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the committee is a task force. It usually has the advantage of 
being time limited. 

It is suggested that your use of committees is a good thing - 
if you take precautions. Write out what it is supposed to ac- 
complish. Pick the chairman and members carefully. Instruct 
the chairman as to what you want done. State how the conclu- 
sions and recommendations are to be presented. If necessary, 
put boundaries on the conclusions to be reached. State the 
time duration of committee operation . 

24. Project Design Reviews 

Reviews, like reports discussed previously, can be over- 
whelming. Much of what was given on reports control could apply 
to reviews control. Yet reviews are vital. They are the way to 
stay current. They are the means of applying your personal 
touch. They are the means of probing in depth as. required. You 
should not just let reviews accumulate indiscriminately. Look 
over the possibilities and decide from the beginning what reviews 
you desire. 

Some of the types of reviews now used by NASA include: 
Administrator Reviews 
Associate Administrator Reviews 
Center Project Reviews 
Project Plan Reviews 

Work Statement and Specification Reviews 

Preliminary Design Review 

Critical Design Review 

First Article Configuration Inspection 

Final Systems Review 

Prelaunch and Postlaunch Review 

Flight Readiness Review 

PERT Review 

SARP Review 

Coordination Committee Review 
Monthly or Bimonthly Contractor Review 
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Customer Acceptance Readiness Review 

Design Certification Review 

Delta Reviews 

Operations Reviews 

Specific Problem Reviews 

Management Reviews 

Periodic Technical Reviews 

Subcontractor Reviews 

Configuration Reviews 

Periodic Project Reviews 

R&QA Review 

Safety Review 

There are other reviews, but the above cross section shows that 
many reviews can exist and that they must be laid out carefully 
to accomplish your particular needs. Preparation of and con- 
ducting reviews is expensive, but usually money well spent. They 
should be carefully thought out in two respects. You should 
decide just what reviews you want to have and you should decide 
just what material should be presented in each type of review so 
that you have coverage without repetition. There are other 
decisions. Which reviews will be held at the contractors' plant? 
What level of speakers do you desire? Which reviews should just 
precede your briefings of higher headquarters so as to provide 
material? What attendance do you desire for each review, particu- 
larly where travel is required? Should you invite upper levels 
of management to reviews at your level? 

25. Visits to Contractors 

A seemingly minor item that has at times been trouble is 
visits to contractors’ plants. A number of people have a need 
to see the hardware and contractor personnel firsthand. These 
usually are various levels of government personnel and other 
contractors involved in the project at a similar level. A good 
way to accomplish this is to conduct some reviews at the plant 
so that these visits can be made at a few controlled times. 
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It may not be necessary to totally control visits to the 
contractors plant but if uncontrolled visits arc overdone there 
are a number of effects. One is that certain key government 
personnel can "tie up T ' a number of contractor personnel who are 
obligated to meet their requests. This on any scale can be 
expensive and delay your project. Another problem is the effect 
of the visit of a number of technical personnel. It is true 
that all changes must go through a change control board and 
that technical design is accomplished by the contractor, but 
government technical personnel can perturb this process in a 
variety of ways if you allow it. Another problem is nontechnical 
policy and direction. You should be the only source of direction. 
If various levels of government management are in the hallway of 
the plant, it is inevitable that there will be confusion on 
just what certain policy or direction is. 

26. Travel and Overtime 

Items such as travel and overtime are often treated as pure- 
ly administrative, but are in fact considerably more important 
than that. For one thing if travel and particularly overtime 
are consistently running at a high rate the items are expensive. 
Also if they run consistently higher than planned, there is 
something wrong with the project or the contract. The contractor 
did not bid on the contract on the basis of doing it on overtime. 
If this is the case you will want to find out why and no doubt 
stop it. The same thing applies to any in-house government 
work that you may be supporting for your project. In fact the 
in-house work often requires more control on these items than 
the contractor. 

You should expect a reasonable amount of travel both in- 
house and by the contractor. Also it is seldom worthwhile 
initially at least to control travel to too low a level. How- 
ever, it is suggested you establish policies by department; 
engineering, manufacturing, etc., according to your own situa- 
tion. You may, for instance, desire that engineering not 
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average over five percent overtime in any quarter. Addi- 
tional overtime beyond that policy may require some particu- 
lar approval. Then you should have overtime and travel tracked, 
.just in the context of your policy. The figure given may not 
b<- the right one for your project, but a consistently high 
figure usually requires some action. 

27. Unsolicited Proposals 

This is a small but interesting item. One usually thinks 
of proposals as being for major new projects. They can be. They 
can be for add-ons to your project and they can be for changes 
to your project. You are aware that these proposals can be a 
product of the projects engineering organizations or they can 
be a new projects group charged directly to your project. As 
such the proposals coming from these organizations may result 
in appreciable cost. 

The other side of the question, however, is whether you 
desire such proposals or whether you do not. Some circumstances 
lend themselves to one approach or the other. For instance, if 
your project is the type that an advanced follow-on version is a 
natural thing you may desire to have someone working on it. If 
you are having difficulty with some advanced aspect of your pro- 
ject, such as the discrimination by earth resources equipment, 
you may want someone working on better approaches. On the other 
hand, for instance, if the technical group you have evaluating 
such proposals is working too closely with the contractor group 
making the proposal you may want to discourage submission of 
proposals. It is probably sufficient to be aware of the possi- 
bilities, observe your own situation, and act if required. 

28. Ethics 

The engineer is oriented to a world where facts are facts 
until proven otherwise. Ethics is concerned with the world of 
values and principles of human conduct. The practice of ethics 
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is one of the social responsibilities of managers. It is a 
problem of universal concern. Unethical conduct is highly 
publicized wherever it is found. Yet it is a problem which 
is very difficult to get hold of because there is not yet a 
science of ethics having generally accepted principles. 

The question of what is right and what is wrong is sub- 
jective at best. The answers are not scientific but are based 
on good intent. There are relationships of ethics to morals, 
but they are not the same. Therefore, no one yet has written 
out successfully a set of ethical codes for NASA or any other 
agency. Boundaries are somewhat understood but you must set 
your own approach. 

The President of Rotary International suggested four guides. 
Ask yourself: 

Is it truth? 

Is it fair to all concerned? 

Will it build good will? 

Will it be beneficial to all concerned? 

Using whatever approach you like you must consider your pro- 
fessional life, the public, your employers, fellow engineers, 
and your contractors. It is suggested you set some maximums 
and let them be known to your office. Is dinner with your con- 
tractor all right? Every week? Can you accept a commemorative 
metal depicting your project? Made of gold? Remember this is 
important also because you are showing the way to those who 
work for you. 
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CHAPTER VIII 


LOW COST APPROACH 

This is the final chapter, and it seems appropriate to dis- 
cuss doing NASA projects for less. Costs were discussed in 
Chapter VI, but that was in the context of cost control and 
cost accounting. Here we are looking at the history of rising 
costs, the history of some overruns and the stabilized or 
somewhat lower NASA budget and asking ourselves how we can con- 
tribute toward doing projects at a lower overall cost. 

This general subject is of sufficient concern to NASA that 
a Low Cost Evaluation Project was set up by the NASA Adminis- 
trator in May of 1972. The NASA Deputy Administrator has re- 
peatedly sought to reduce the cost of NASA projects and has 
stated, "If we don't do something about the high cost of doing 
business in space, and do it soon, our nations space program is 
in deep trouble. If we don't find a way to do more for our 
money, we may lose our hard-won worldwide leadership in space." 
This warning is well timed and we should all heed it. Perhaps 
the best way to start is to list the eleven cost principles 
given by the NASA Deputy Administrator: 

1. Don't reinvent the wheel. Use the best that is available 
from other programs. 

2. Standardize - Including parts, components, modules, to sub- 
systems and entire systems. 

3. Design for low cost. Involves production engineering in the 
earliest stages of design. 

4. Design to minimize testing and paperwork. Take advantage 
of reduced weight and volume constraints and use standard 
parts, larger margins and larger safety factors. 
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5 . 


Recognize that different systems can accept differing 
degrees of risk. Where possible, the cost of a system 
should reflect the acceptance of risk. 

6. Know your costs. Accurate cost estimating must be developed. 

7. Trade features for cost. Consider requirements as goals. 

8. Pay particular attention to the few very high cost items. 

9. Know your costs before you start. The most fundamental of 
all requirements. 

10. Set firm cost targets. Desire for the lowest possible cost 
is not a good approach. 

11. Meet the established cost targets. Find ways to meet tar- 
gets, no matter what happens. 

These are excellent principles, subtle in places, and well thought 
out. If you understand and implement these eleven principles 
alone, you will be taking major strides toward low cost. 

The efforts of the Low Cost Evaluation Project, referred to 
above,will not affect current projects such as Shuttle as much 
as they are expected to affect payloads for Shuttle and other 
later projects. Reducing these costs will be a necessity if 
NASA is to fly the number of payloads it will have the capability 
of handling. The principal product of the low cost project thus 
far is possibly two things: First, a determination to sacrifice 

some performance and utilize the Shuttle payload capacity or 
design approaches necessary to avoid tight margins. Second, to 
issue a catalog of standardized subsystems for future space- 
craft housekeeping functions. These subsystems then would re- 
duce new developments and emphasize reliability. This catalog 
will emphasize subsystems such as in power, communications, 
propulsion, guidance, navigation, telemetry, attitude control, 
data processing, environmental control, etc. These approaches 
are fundamental and should effect cost savings. It will be 
necessary to do much more if NASA is to move on as it should. 

The cost project has studied a number of other approaches. 

Low cost projects are somewhat the result of various 
individual approaches by cost conscious managers. It's an 
awareness, an attitude and a drive. Possibly everything that 
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works for one will not work lor another. However, if you 
consider enough approaches used by others, some may appeal to 
you and, hence, may help. The most useful one of all is to 
make clear your intent and policy. If your decisions overlook 
cost, everyone will notice and you cannot expect an effort to 
reduce costs by others. If you are truly intent on making your 
project a low cost one, then in addition to the comments above by 
the Deput y NASA Administrator it will be useful to list for you 
some low cost ideas that have derived from studies by the Low 
Cost Evaluation Project and some others developed by industry. 
These suggestions do not necessarily have status, but are some 
of the products of the efforts of these groups. 

Some of the work done by the Low Cost Evaluation Project 
was intended for management levels above yours. However, in 
all cases it is useful to know the actions suggested for those 
levels and in most cases you can play an active part in helping 
to realize these objectives. Some items that fall into that 
category include; 

1. Establish realistic program plans for the agency. 

2. Assure that each program is well defined and accurately 
estimated before Phase C or even Phase B. 

3. Set realistic flight dates. 

4. Insist on a low cost approach. 

5. Require a risk analysis before Phase C. 

6. When budgets are cut eliminate line items instead of 
deoptimizing all programs. 

7. Push parts standardization. 

8. Push for more NASA participation in overhead negotiations. 

9. Establish a policy for trading risk and cost. 

10. Assign resources to the low cost programs. 

11. Minimize interfaces in assigning missions for each program. 

12. Make firm budgets a policy - cut programs to fit budgets. 

13. Avoid dead end projects. 

14. Establish minimum requirements for data. 

15. Resist changes. 

16. Establish and pursue an employee cost consciousness program. 
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17. Improve cost estimating and risk assessment techniques. 

18. Develop a program which prepares engineers for project 
management to include a cost management capability. 

19. Insure that low costs and realistic estimates are em- 
phasized in the contractor selection process. 

20. Insure that standarization and off the shelf utilization 
is a requirement for Phase B. 

21. Insure that cost improvement and risk analysis are require- 
ments for Phase B. 

22. Insist on a policy of effective management tools to control 
cost and risk. 

23. Perform studies and initiate programs on uses of standardi- 
zed parts. 

24. Consider the use of value engineering and other existing 
assurance programs. 

25. Provide training which will contribute to cost effective 
projects. 

As you can see, many of the things that upper management 

can consider are also within your pervue. Attempting not to 

repeat too many items there are also some items that more 

specifically fall just to your own consideration: 

1. Use risk, cost, performance analyses on important trade 
off studies. 

2. Assure that everyone in your project understands that you 
want lowest cost at an acceptable risk. 

3. Have acceptable risk defined for each system and subsystem. 

4. Be sure your test programs consider already qualified parts, 

5. Minimize and simplify all project interfaces - both people 
and hardware. 

6. Use extra weight or space where possible to simplify test- 
ing or design. 

7. Minimize nonflight hardware and standardize it where 
possible . 

8. Ship test hardware where possible to reduce number of sets. 

9. Have crews travel with hardware where possible and avoid 
multiple shifts, for continuity. 
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10. Reduce presentations, meeting, etc. ; 

11. Make an experimenter more responsible i'or the performance 
of his equipment. 

12. Don't assume the contractors responsibility at first trouble. 

13. Negotiate a contract where small changes are in the base 
price to avoid paperwork. 

14. Use incentives and awards for low cost approaches. 

15. Eliminate new technology where possible. 

16. Provide leadership and motivate participants to low cost. 

17. Find ways to utilize the Work Breakdown Structure as a 
tool to control costs. 

18. Validate the contractors approach before any trouble occurs. 

19. Know your requirements. 

20. Understand your costs in detail. 

Again, many of the items listed above apply to the con- 
tractor as much as they do to you, or the Center, or NASA Head- 
quarters. There are some items the contractor should specifi- 
cally consider, however: 

1. Identify problems early and surface them for all to see. 

2. Shorten communication lines. 

3. Utilize existing inventories, GSE, facilities, etc. 

4. Restrict changes to make-work. 

5. Concentrate on improving cost estimates and related manage- 
ment practices. 

6. Keep layers of management to as few as possible. 

7. Continuously review requirements for validity and effectiveness. 

8. Select proven vendors. 

9. Use a simple but complete drawing release system. 

10. Be willing to chance some understaffing. 

11. Discuss requirements causing heavy staffing. 

12. Be willing to staff down. 

There are of course many other suggestions which will fit 
all or some layers of project management. If these suggestions 
get you to thinking how you can be cost conscious they will have 
served their purpose. When one thinks about how to reduce costs, 
responsible suggestions do not differ that much in approach. It 
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is the execution that is different. To show the similarity, 

.just different phrasing, listed below is a set of suggestions 
on cost savings developed by a prime contractor: 

Management 

1. Use small co-located project teams. 

2. Shorten project schedule as much as practical. 

3. Stay on schedule. 

4. Optimize funding curve for project. 

5. Control changes. 

6. Keep same customer and contractor key people throughout 
project life. 

7. Reduce layers of management. 

8. Perform good planning. 

9. Make detailed cost assessments. 

10. Make all personnel aware of cost savings need. 

11. Make the managers combined business and technical managers. 

12. Use Value Engineering and profit sharing to motivate con- 
tractors . 

13. Standardize management and cost reporting systems. 

Technical 

1. Use off-the-shelf designs. 

2. Use higher design margins and less testing. 

3. Eliminate engineering models by using standard electronic 
packaging. 

4. Reiurbish qualification parts for use as spares where 
appropriate . 

5. Plan, schedule, and require only one set of GSE. 

6. Minimize nonflight hardware. 

7. Use model shops for short runs of advanced hardware. 

The Department of Defense guidelines are direct and to the point 

1. Reduce concurrency. 

2. Design to cost. 

3. Use the prototypes. 

4. Complete the hardware. 

5. Reduce industry design teams. 

6. Minimize detailed requirements. 

7. Increase test and evaluation prior to procurement decision. 
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Department of Defense, as others, is also recognizing the 
need to state a policy of permissible risks and to accept 
more and more risks. Also, more and more the government is 
looking for the best possible job at a fixed cost. This re- 
quires DOD, NASA and others to become more used to assembling 
space projects than developing them. Commercial practices for 
new products should be adopted where possible. 

A low cost development project is the most difficult project 
of any you can undertake. It requires small but strong pro- 
ject offices, teamwork, responsible contractors and vendors, 
constant cost checking, clear requirements, a cost ceiling 
attitude, visibility, ability to trade performance for cost, 
and dogged determination. Since such a task requires such an 
organized and disciplined approach, many will argue that the 
low cost approach, to be successful, requires greater use of 
the assurance technologies; value engineering, reliability 
assurance, quality assurance and configuration management. 

It can be shown that such disciplined programs, properly imple- 
mented and managed, pay for themselves many times. The disci- 
pline alone is conducive to low costs. Countless charts exist 
to show the savings these programs have produced. The key to 
such savings is management support and understanding. 

Perhaps for completeness we should pause and consider two 
of the largest cost drivers in R&D. These are related and can 
be considered major unresolved problems. Complete solution is 
beyond your scope, but a short discussion here, hence knowing 
where the real problems are, does help your own cost effective- 
ness program and help in putting project costs in perspective. 
These problems are our present methods of competitive source 
selection and the related situation of out-of-scope changes 
added to the contract. The competitive source selection is re- 
quired by law for several good reasons. However, the fact that 
the selection is competitive, and costly, does add to your 
problems of developing at low cost. If you have a normal R&D 
project, presumably several contractors have spent a large 
amount of money and used top talent to bid on the contract. 
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Although NASA is departing from source selection by the low- 
est bid, it is still very important and the contractor is 
considered to be developing to the total cost he described. 

Also NASA is doing a much better job of describing the re- 
quirements before proceeding. In fact, from a technical point 
of view the projects are now sufficiently described before 
any projects are initiated. Only the strongest and most com- 
petent government management can control these costs in today's 
situation. Since the bidding was cost competitive and since 
the NASA budget is restricted also, the best possible situa- 
tion would be to build the item described if nothing went 
wrong and if no changes occurred. 

Now let us briefly look at the control of all changes. 

There is no easy way to turn a government in-house capability 
loose and not find a myriad of other management and technical 
changes that really need to be made, i.e., the vibration test 
conditions have a new input, or a schedule change, or a new 
report is required. The contractors know this. To them it is 
both a way to take care of any cost omissions in the project 
from the bidding and it is also a government input too large 
to absorb as it exists today. The contractor therefore in- 
sists on out-of-scope changes as well as in-scope changes, 
resulting in a tremendous amount of traceability documenta- 
tion for hundreds and thousands of changes per project. This 
overall situation is perhaps the most costly thing in the 
development project and can be solved only by new legisla- 
tion or by you. 

It is hoped that innovative new legislation will improve 
the above situation. Until then, however, you are the only 
control element in the loop. You cannot alter too much the 
contractor selection process and the resulting situation it 
causes. However, you can hold down changes. The technical 
personnel naturally will want to improve a project. It takes 
real leadership to keep the Center's technical personnel 
interested and a part of the project to assess proposed changes, 
etc., and yet to turn them down on most of the changes they 
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consider necessary. Yet, this is what is required. To keep 
morale high and everyone involved in a project that is not 
being improved is not easy. 

In summary, the task of accomplishing a low cost pro- 
ject is very difficult, like "swimming up stream.” A project 
organization is a "high morale” group. Everyone is dedicated 
to driving on and accomplishing a difficult technical job on 
time. For one to interpose rigid cost control methods is to 
appear to be out of step. It is not a popular position, ex- 
cept with top management or financial groups. All other 
Center, project, and contractor personnel may feel restricted 
by cost savings. It is not an easy task. Every other feature 
of the project - performance, risk, schedules, etc. - demands 
higher costs. Therefore, for you to set your goals on a low 
cost project and achieve it, you will have to be dedicated 
and skillful. However, it can be done. It requires your 
own brand of innovation. One example; have you ever considered 
when your Center technical personnel find a vibration test 
that is really insufficient, NOT writing a change order? In- 
stead, writing a contract letter to the contractor saying it 
is the opinion of the government that the vibration tests are 
insufficient, but that the contractor must finally decide. A 
contractor would find such a letter hard to ignore; yet you 
have not increased the ceiling of the project. This suggestion 
is only to let us realize there are other ways of doing business. 
You must find the ways that fit you best. 
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APPENDIX A 


AMIRS 

ATR 

CCB 

CDR 

CEI 

CM 

COFW 

CPFF 

C/9PCS 

DCR 

DIR 

DOD 

DRD 

DRL 

ECP 

ECRC 

FAC I 

FARADA 

FM 

FMEA 

FRR 

g ’s 

GFE 

GREMEX 

GSE 

HI-REL 

ICD 

IDEP 

IDWA 

IR&D 

JSC 


ACRONYMS AND ABBREVIATIONS 

Apollo Management Information and Retrieval System 
Apollo Test Requirements 

Configuration Control Board (Change Board) 

Critical Design Review 
Contract End Item 
Configuration Management 
Certification of Flight Worthiness 
Cost Plus Fixed Fee 

Cost/Schedule Planning and Control Specification 

Design Certification Review 

Document Information Record 

Department of Defense 

Data Requirement Description 

Data Requirement List 

Engineering Change Proposal 

Electronic Component Research Center 

First Article Configuration Inspection 

Failure Rate Data (Exchange Program) 

Frequency Modulation 
Failure Mode and Effect Analysis 
Flight Readiness Review 
Gravity 

Government Furnished Equipment 

Goddard Research Engineering Management Exercise 
Ground Support Equipment 
High Reliability 
Interface Control Document 
Interservice Data Exchange Program 
Interdepartmental Work Authorization 
Independent Research and Development 
Johnson Space Center 
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MAIDS 

MINK 

MIS 

MIRADS 

m ods 

MQ&P 

MSFC 

MS F/ DPS 

NASA 

NHB 

NMI 

NPC 

O&M 

OMSF 

PAD 

PDR 

PERT 

PMS 

POP 

PP 

PPP 

QPL 

R8cD 

R8cQA 

RFP 

RID 

SARP 

SE 

SEB 

SOW 

spec s 

SRT 

TU 

VE 

WAD 

WBS 


Management Automated Information Display System 
Management Information Network Extension 
Management Information System 

Marshall Information Retrieval and Data System 
Modifications 

Monthly, Quarterly, and Performance (Financial Reports) 

Marshall Space Flight Center 

Manned Space Flight/Data Processing System 

National Aeronautics and Space Administration 

NASA Handbook 

NASA Management Instruction 
NASA Publication Control 
Operating and Maintenance 
Office of Manned Space Flight 
Project Approval Document 
Preliminary Design Review 

Performance Evaluation and Review Technique 

Performance Measurement Specification 

Program Operating Plan 

Project Plan 

Phased Project Planning 

Qualified Parts List 

Research and Development 

Reliability and Quality Assurance 

Request for Proposal 

Review Item Discrepancy 

Schedule Analysis and Review Procedure 

Systems Engineering 

Source Evaluation Board 

Statement of Work 

Specifications 

Supporting Research and Technology 

Technology Utilization 

Value Engineering 

Work Authorization Document 

Work Breakdown Structure 
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